Unfortunately, as the Jitsi Meet development evolved the routing mechanism
became more complex and thre logic ended up spread across multiple parts of the
codebase, which made it hard to follow and extend.

This change aims to fix that by rewriting the routing logic and centralizing it
in (pretty much) a single place, with no implicit inter-dependencies.

In order to arrive there, however, some extra changes were needed, which were
not caught early enough and are thus part of this change:

- JitsiMeetJS initialization is now synchronous: there is nothing async about
  it, and the only async requirement (Temasys support) was lifted. See [0].
- WebRTC support can be detected early: building on top of the above, WebRTC
  support can now be detected immediately, so take advantage of this to simplify
  how we handle unsupported browsers. See [0].

The new router takes decissions based on the Redux state at the time of
invocation. A route can be represented by either a component or a URl reference,
with the latter taking precedence. On mobile, obviously, there is no concept of
URL reference so routing is based solely on components.

[0]: https://github.com/jitsi/lib-jitsi-meet/pull/779

* fix(connection): reload immediately on possible split-brain

There isn't an explicit way to know when a split brain
scenario has happened. It is assumed it arises when an
"item-not-found" connection error is encountered early
on in the conference. So, store when a connection has
happened so it be calculated how much time has
elapsed and if the threshold has not been exceeded
then do an immediate reload of the app instead of
showing the overlay with a reload timer.

* squash: rename isItemNotFoundError -> isShardChangedError

This commit adds a state getter that considers checking the enabled/disabled state of the calendar feature, so then other features don’t have to do it manually.

Very likely I broke something subtle and I'm prepared to fix it.

WebRTC plugin support has been axed, this is now dead code.

Adds a fatal error state on which will depend whether or not the reload
screen is to be displayed. It is to happen when a relevant fatal error
action is not claimed by any feature for error recovery (the recoverable
flag is not set).

- Instead of having 4 listeners for local connection status
  updates and 1 for remote, remove two of the redundant listeners.
- Instead of calling into 4 separate VideoLayout methods to update a
  participant's connection status, expose one handler.

Up until now, mobile was oblivious to participants' presence state. Presence
state handling is required (probably, amongst other things) for "call flows".
So, let's add it! This is done by gathering the presence state when a
participant first joins, and handling subsequent changes.

Fix the "mute ping pong" for once and for all. This patch takes a new approach
to the problem: it keeps track of the user generated CallKit transaction ations
and avoids calling the delegate method in those cases.

This results in a much cleaner and easier to understand handling of the flow: if
the delegate method is called it means the user tapped on the mute button. When
we sync the muted state in JS with CallKit the delegate method won't be called
at all, thus avoiding the ping-pong altogether.

In addition, make sure all CallKit methods run in the UI thread. CallKit will
call our delegate methods in the UI thread too, thsu there is no need to
synchronize access to the listener / pending action sets.

Not all TRACK_ actions include the `local` attribute, so use the underlying
`jitsiTrack` to check it.

* ref(video-layout): move middleware for TRACK_ADDED

* ref(video-layout): call mucJoined when redux knowns of conference join

old values: 0-39% -> red, 40-69% -> yellow, 70%+ -> green
new values: 0-9% -> red, 10-29% -> yellow, 30%+ -> green

* ref(info): use conference existence as trigger for autoshowing dialog

* squash: combine maybeShow checks, inheritdoc

* squash: flow type tweaks

* feat(settings): setting dialog

- Move device selection, profile edit, language select, moderator
  options, and server auth into one modal with tabs.
- Remove side panel profile and settings and logic used to update
  them.
- Pipe server auth status into redux to display in the settings
  dialog.
- Change filmstrip only device selection popup to use the new
  stateless settings dialog component.

* squash: do not show profile tab if not guest

* squash: profile button not clickable if no profile to show

* squash: nits

* ref: Settings dialog.

On web CONFERENCE_FAILED handlers are not setting the 'recoverable'
flag thus any middleware which rely on those should not execute on web.

Emits CONFERENCE_FAILED in response to CONNECTION_FAILED event
which then triggers JitsiConference.leave() through the middleware
processing. Also base/conference state will be adjusted. It is to have
a consistent redux state in which both connection and conference are
failed. It could happen that in a buggy environment the XMPP connection
is dropped, but the media is still flowing which would result in weird
user experience.

The change to mobile/external-api is required to not emit
CONFERENCE_FAILED for CONNECTION_FAILED if the conference has been
started, because base/conference state will still hold conference
instances which are to be ended by other means and result in the
appropriate event (which will adjust the base/conference state).

Currently the listeners for disconnected and failed connection events
are unsubscribed as soon as the connection is established, so
the CONNECTION_DISCONNECTED is never triggered which would clear the
'connection' field. This commit will clear the 'connection' state on
CONNECTION_WILL_CONNECT. It's needed anyway given that there's no
guarantee on when and if the async disconnect operation will finish.

One issue caused by the 'connection' not cleared was that
CONNECTION_FAILED was not reduced correctly and the reload screen was
not displayed for the following scenario:
1. Join and leave any working conference.
2. Turn off network connectivity on the device.
3. Wait for CONNECTION_FAILED. The reload screen will not be displayed,
   because CONNECTION_FAILED is not reduced correctly, because the old
   'connection' value is still there.

Your truly introduced this regression in
8c7a3f16b1, alas.

The audio only mode is used to set the CallKit call type. This affects the
behavior on the recent calls entries (calls are marked either as audio or video
calls).

Sync both at the start and for transitions. The previous code was working by
chance (in a way): when the CallKit UI is presented the local video is muted,
which triggers a SET_VIDEO_MUTED action, at which point the audio-only mode was
checked for. Now we are more explicit and act on SET_AUDIO_MUTED.

Rely solely on actual track state, rather than the desired state, (what
base/media represents).

Read the muted state from the track itself instead of from base/media. This
avoid expressing the incorrect desire when the call starts muted because
permission was never granted.

Audio muting does not have an authority.

* ref(large-video): permanently enable canvas based background

* squash: leave flag for disabling background