Only on web, since there is currently no equivalent on mobile. It encapsulates
all funcionality related to opening the settings dialog / panel.

Use the new abstractions, which already take care of the rendering part.

Currently the following are implemented:

- AudioMuteButton
- HangupButton
- VideoMuteButton

In order to implement these new buttons a new abstract class was introduced,
which abstracts the ToolboxItem into a button with enough hooks so a stateful
and a stateless version of it can be created.

This patch only adds the stateful implementation of the aforementioned buttons.

This abstraction represents an action which can go anywhere in a toolbox (be
that the main toolbar or the overflow menu) and it's platform independent.

It does not depend on Redux, thus making it stateless, which facilitates its use
in stateful button implementations as well as stateless ones.

Releases are also published to jcenter, and due to how the dependency is
declared, we are picking the latest release from there, which is arguably not
what we want.

Includes a fix for compatibility with RN >= 0.47.

Knowledge is power, man!

The config.js cache predates the feature base/known-domains.
Technically, it's also able to recall more domains that the feature
recent-list can (because the latter limits its entries).

Knowledge is power, man!

We moved "knownDomains" from calendar-sync to base/known-domains.
However, we do have an official release in the app stores and I'd like
us to not throw away the knowledge it has acquired.

Adding cancel to mod_muc_call

If authenticated using JWT, don't show the profile button but
do show it if a guest.

It needs to be global and the old replace seems to escape only the first
occurrence.

[Android] Fix possible TypeError in multi-JitsiMeetView SDK consumers

If multiple JitsiMeetView instances are created (not necessarily
existing at once), it's possible to hit a TypeError when reading the
React Component props of the currently mounted App. Anyway, in certain
places we're already protecting against that out of abundance of caution
so it makes no sense to not protect everywhere.

[RN] Refactor SimpleBottomSheet

Make it more generic by accepting any content except of just rows with text and
icons.

In addition, rework its structure so the animation is smoother, by putting the
background overlay outside of the Modal. This way, the animation doesn't affect
the background, which won't slide down.

* fix(toolbar): make button hover bigger

* fix(toolbar): make hangup button bigger

* fix(always-on-top): make toolbar and buttons same sizes as main toolbar

* fix(toolbar): change some tooltips

* fix(toolbar): adjust side panel and filmstrip for new toolbar sizes

Introduce ConnectionFailedError type.

Delay the CONFERENCE_FAILED event until the user cancels the login
dialog using the 'recoverable' event flag.

It seems that the external API will not send any event to let the sdk
consumer know that the conference has failed if the problem occurs at
the establishing of XMPP connection stage. That's because the config was
loaded successfully, but the conference instance does not exist yet, so
neither base/config nor base/conference will emit any failure.

Make the external API emit CONFERENCE_WILL_JOIN early on SET_ROOM action
which occurs before the XMPP connection is created. At this point we
know that config has loaded and if there's a valid conference room to
be joined. We were thinking of doing that even on CONFIG_WILL_LOAD,
but that seemed to be to risky at this point.

With this the RN component and the consumer app can share same CallKit
provider, configuration, and enable to be part of multiple listeners of
the CallKit flow events. The main driver of this is to enable the
consumer app to be able to report an incoming call to the OS before
loading the JitsiMeetView. Once the user answers the call, the app can
instantiate a JitsiMeetView, pass the CallKit call UUIID, and the Jitsi
Meet components will handle the connection and report back to CallKit
that the  call has been established.

Hristo Terezov, Chris Cordle, and I/Lyubomir Marinov agreed that we'd
try to use "invite" & "invitee(s)" in Web/React's iframe API,
mobile/react-native's SDK invite API, and internally for the purposes of
consistency, ease of understanding, etc.