CHI-2916 switchboarding

[mythilytm]

Description

This PR introduces the Switchboarding allowing supervisors to enable and manage switchboarding for a specific queue.

• The UX adds a tile to the queues page and enables the routing of calls in selected queue.
• We use Twilio Sync to store and get the state of the current switchboarding time, queue and the counsellor which initiated it.

Checklist

• Corresponding issue has been opened
• New tests added
• Feature flags added
• Strings are localized
• Tested for chat contacts
• Tested for call contacts

Other Related Issues

None

Verification steps

AFTER YOU MERGE

1. Cut a release tag using the Github workflow. Wait for it to complete and notify 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]

In general, this looks awesome to me! I like the approach you are taking to implement the feature.

Sorry to leave so many comments, some of them are to make sure we are addressing edge cases, some of them are just questions.

One question I want to make that does not fits any of the files: Do we really need to have a Redux state that mirrors the sync document state? Maybe the sync document itself can carry loading and error information as well as the data required for switchboard, and having the Redux state would be unnecessary?
I LOVE the implementation you have around all of this using custom hooks (useSubscribeToSwitchboardState and useToggleSwitchboardingForQueue), which make me wonder, maybe just the hooks and the sync client could handle everything without Redux? #2991 (comment)