Use subscribers to detect state change and emit those
out to other participants. Use middleware to register
the command listener.

Searching for a device (id) by label alone can result in
false results when devices share labels, such as a mic
and speaker having the same label. To prevent such,
specify the device kind to be found instead of iterating
over all device kinds.

When the iFrame api is used to set a preferred audio output using
options passed into the JitsiMeetExternalAPI constructor, no logic
fires to actually change the audio output destination.

If tracks are created while the conference is in the 'joining' state
they will never be added.

🔥🔥🔥

Using anything non-serializable for action types is discouraged:
https://redux.js.org/faq/actions#actions

In fact, this is the Flow definition for dispatching actions:

declare export type DispatchAPI<A> = (action: A) => A;
declare export type Dispatch<A: { type: $Subtype<string> }> = DispatchAPI<A>;

Note how the `type` field is defined as a subtype of string, which Symbol isn’t.

That's what the SDK passes now, if the room URL is not absolute.

* Updates recording dialog.

* Update config.js doc.

* Adds comment and make a check more intuitive.

* Changes of using enum for recording types.

* Adds new format of phoneList service and re-design dial in numbers page.

Adds flags and country names (with translations) for the numbers if using the new format.

* Fixes tests and fixes get default number.

* Updates swagger with new format.

* Moves html back yo table.

Fixes displaying on mobile and also the tel: URI generation. The tel: URI is tested on Android and iOS and seems to work (Android was not interpreting 'p', but both seems to like ',').

* Fixes a wrong return statement.

* Small fixes.

A reducer must always return a state or null to ignore it. When the color scheme
is undefined we should return the previous state.

This reverts commit 7c911eca96.

I'm dumb. We need global mode because otherwise lastIndex is not updated in the
regex object, which we rely upon, so this is intentional.

The logMessage can be very long. Probably only it's length could be
important to why sendApplicationLog has failed. Stringify the error
though.

Stores the Logger.LogCollector instance in base/logging state instead of
global APP variable and enables it on mobile.