CHI-2961: converation direct transfer queue

[stephenhand]

Description

Use the 'Everyone' queue for direct transfers if it is available to the target worker. This will make the behaviour a little more consistent

Checklist

• Corresponding issue has been opened
• N/A New tests added
• N/A Feature flags / configuration added

Other Related Issues

None

Verification steps

Do a direct chat transfer of a conversation but don't accept it yet.
Check the task on Twilio Console - it should be in the 'Everyone' queue
Repeat for different channels and helplines, it should always be in the 'Everyone' queue if it is visible to the target worker

AFTER YOU MERGE

1. Cut a release tag using the GitHub workflow. Wait for it to complete and the notification to be posted in the #aselo-deploys Slack channel.
2. Comment on the ticket with the release tag version AND any additional instructions required to configure an environment to test the changes.
3. Only then move the ticket into the QA column in JIRA

You are responsible for ensuring the above steps are completed. If you move a ticket into QA without advising what version to test, the QA team will assume the latest tag has the changes. If it does not, the following confusion is on you! :-P

[GPaoloni]

Why is using Everyone queue making things more consistent? And what problem is this one trying to solve? 🤔

I don't say we shouldn't do this, just bear in mind that the contacts will be saved as "Everyone" in the DB and information about what queue they came from is lost.

[stephenhand]

@GPaoloni - sorry, the context for this is that for conversations, direct transfers arbitrarily choose the first valid queue for that worker, so the queue of origin for the task is lost anyway

Because we are using Flex Interactions API rather than the one we were using for programmable chat, we need to set a queue explicitly for direct transfers