Without dominant speaker in redux, the wrong user will be
selected after an unpin event.

Filmstrip only mode displays a device selection dialog that
does not have access to the redux/connect. However, the current
VideoTrack extends from AbstractVideoTrack, which assumes a
redux connection. The fix is to move video display logic into
a separate component and have device selection use that, while
the existing VideoTrack remains connected to redux but
uses the new video display component.

Don't require autofocus because that prevents the app from appearing in
Google Play Store for some devices.

Don't require camera for the same reason but also because camera/video
is not a mandatory feature of the app, it's merely likely very
desirable.

In Chrome M63 a warning is shown, permissions won't be automatically allowed
afterwards. Reference:
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-permissions-in-cross-origin-iframes

Setting this early makes us future proof, while working with current versions
too: Chrome < 63 gives an error because it doesn't understand the option and
Firefox seems to ignore it, so both continue to work as before.

The class ReflectiveOperationException used in ExternalAPIModule was
introduced in API level 19.

Based on work authored by Shuai Li <sli@atlassian.com>, Daniel Ornelas
<dornelas@atlassian.com>, and Lyubo Marinov <lmarinov@atlassian.com>.

Instead of going through the Avatar object, call the getAvatarURL
directly so that the code flows consistently use the participant
representation within redux.

In certain scenarios we do need to import files instead of features but
even then it is our coding style to not write the file extension.

We broke external_api.min.js by importing react/features/util which
imported react/features/base/lib-jitsi-meet.

1. To reduce the risks of such a breakage until we add
   external_api.min.js to the torture tests, import as little as
   possible in modules/API/external/external_api.js.
2. Use the global JitsiMeetJS on Web in react/features/base/util.

JitsiMeetViewListener is an integral part of the public API of Jitsi
Meet SDK for Android. Utilize it in the Debug configuration of the Jitsi
Meet app for Android in order to increase (1) awareness of API breakages
and (2) API coverage.

The same goes for JitsiMeetViewDelegate in Jitsi Meet SDK and app for
iOS.

The error is stored in the redux store in base/config so other components can
consult it. It is also broadcasted as a new event in the external API for the
SDK.

JitsiMeetViewListener currently has methods of one and the same pattern
so adding new methods i.e. events i.e. redux action types is a question
of repetition in the Java source code. Speed up the support of new
events by trying to deal with them in a generic way.

The same goes for JitsiMeetViewDelegate.

- Remove references to the model ContactList.
- Replace ContactListView with an empty element for attaching
  the React Component ContactListPanel, which has the same
  features as the old ContactListView.
- Create new selector for getting non-fake participants for
  ContactListPanel's props.
- Create a ParticipantCounter component to place in the contact
  list button. Previously ContactListView updated that but now
  it's a react component hooked into the participant state.
- Remove pub/sub that was used only by ContactListView.

Implement a React Component which displays children as an overlay of
local video. The WelcomePage implemented such a component inside of it
among other WelcomePage-specific logic so I split
LocalVideoTrackUnderlay out of it. The new Component is used on the
BlankPage which may be displayed in the future not only when the
WelcomePage is disabled but also when there are long running network
requests, for example.

This only helps iff there is a short transient network error which prevents the
configuration from being loaded. In such case, use the cached version in
localStorage, which may not match the shard, but it's (probably!) better than
nothing.

In case there is no Internet connectivity, an error will be produced as soon as
the XMPP connection is attempted anyway.

It's built on top of React Native's AsyncStorage. They have differing APIs, so
we implement a synchronous API on top of an asynchronous one. This is done by
being optimistic and hoping that operations will happen asynchronously. If one
such operation fails, the error is ignored and life goes on, since operations
are performed in the in-memory cache first.

Note to reviewers: LocalStorage.js lacks Flow annotations because indexable
class declarations are not yet supported:
https://github.com/facebook/flow/issues/1323 and yours truly couldn't find a way
to make the required syntax work without making it unnecessarily complex.

Specially prior to pod install.

It'snot the end of the world, we can move on.

This patch loads the config later than we used to, that is, only once we
know the room the user is about to join.

Due to architectural limitations in lib-jitsi-meet, it needs to be
initialized with a configuration in order to properly function. This is
unfortunate because we need to create a video track in the welcome page,
but don't know the room (hence no config) yet. In order to circumvent
this problem an empty configuration is used, which is later swapped with
the appropriate one, once loaded.

Some interesting side-effects of this change are a perceived speed
increase when the app starts or a conference is hangup. They are both
due to the fact that no config needs to be fetched from a remote server
in those cases.

For example, while config.js and other files are being loaded before the
navigation to Conference is feasible.

In order to load the configuration from the shard that will actually
host the conference, it's imperative that we add the room= query
parameter:

https://meet.jit.si/config.js?room=example

This implies a departure from our current model, where the config is
discarded if the domain for the next conference is different, but kept
otherwise.