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.

To be consistent with how the main window toolbar has audio mute,
hangup, and then video mute.

This can happen if there are multiple JitsiMeetView instances are active at the
same time, because there is a single bridge, which means all of them would get
the events.

Currently enterPictureInPicture action can only be dispatched when
the app is on the conference view and the enter PiP button is displayed,
so no check should be necessary.

Activity.enterPictureInPictureMode method must be invoked synchronously
on userLeaveHint callback in order to be sure that the current Activity
is still visible (does not transit to PAUSED state). Previously if the
asynchronous processing would be delayed enough for the Activity to go
into the PAUSED state it will be too late to go into the PiP mode.

To reduce the amount of motion that has to be blurred, use a canvas
to essentially set the FPS of the video background. This canvas
component is behind a temporary feature flag, as well as being able
to disable the blur, so it can be played around with on deployed
environments.

It's required by lib-jitsi-meet when using WebSockets.

- Change copy
- Add labels to dropdowns
- Adjust color and positioning

- Update font files to add new icon.
- Update markup and style so the icon has a small background
  to fill in the text of the icon.
- Remove some css transitions that don't seem to do much.

The app will crash for me with react complaining about not a component
being passed.

* feat(icons): add new recording button icon

* feat(toolbar): show different rec/streaming icon

* Separate local thumbnail in filmstrip

* style(Filmstrip.native): utilize full line length

In order to be able to add analytics to the deep-linking pages the
lib-jitsi-meet initialization has been moved so it happens earlier.

The introduced `initPromise` will eventually disappear, once conference is
migrated into React and / or support for Temasys is dropped. At that stage, it
can be turned into a sync function which all platforms share.

* Button conditionally shown based on if the feature is enabled and available
* Hooks for launching the invite UI (delegates to the native layer)
* Hooks for using the search and dial out checks from the native layer (calls back into JS)
* Hooks for handling sending invites and passing any failures back to the native layer
* Android and iOS handling for those hooks

Author: Ryan Peck <rpeck@atlassian.com>
Author: Eric Brynsvold <ebrynsvold@atlassian.com>

* Adds in memory log storage, to be used while testing.

Enabling it only when config.debug is set, a configuration provided by jitsi-meet-torture.

* Moves to using config.testing.testMode property for logs storage.

* Fixes comments.

Activity.enterPictureInPictureMode can fail for a couple of reasons
mentioned in the JSDoc:

"The system may disallow entering picture-in-picture in various cases,
including when the activity is not visible, if the screen is locked or
if the user has an activity pinned."

It seems to be safe to assume that those cases will be caught by
a RuntimeException handler (only RuntimeExceptions can be left without
explicit catch block).

Anyway the root cause for problems is the fact that the current process
for going to the picture in picture mode is not synchronised with
Activity's lifecycle. On Activity's "userLeaveHint" callback we dispatch
async task to the JS code which only then after dispatching some more
stuff eventually call native method that enter PiP. In case we spend too
much time on the JS side and the Activity goes to PAUSED state the call
will fail with IllegalStatException: "activity is not visible",
"activity is paused" etc. This means with this fix the app will not
crash, but we'll see it sometimes not go to the PiP mode as expected.

* feat(recording): show the YouTube live stream URL

- From the start live stream dialog, push up the broadcast ID
  of the chosen broadcast. It is assumed the ID can be used to
  create the YouTube link.
- Listen for lib-jitsi-meet to emit updates of the known live
  stream URL, shove it into redux, and have InfoDialog display
  it.

* ref(info): pass in dial in and live stream url

Passing these values in should trigger AtlasKit InlineDialog
to re-render and reposition itself.

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

* feat(info): add live stream link to invite copy

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

This reverts commit 1072102267.

* hidden -> url

* _onClickHiddenURL -> _onClickURLText

Since the main conference container is no longer "clickable" there must
be a way for clicking on the "large video". A clickable TestHint nested
in ParticipantView makes it easier for dealing with the fact that the
click handler is not always on the same component (required for the
pinch and zoom feature to work correctly).

Allows to bind a click handler to a TestHint.

When a mobile test wants to click an UI element it must be able to
locate it through the accessibility layer. Now the problem with that is
that there is currently no uniform way for finding element on both iOS
and Android. This problem is solved by TestHint component which takes
an id parameter which then can be specified in the corresponding java
TestHint class in jitsi-meet-torture to easily find it. By being able to
add a click handler to a TestHint, it's possible to duplicate original
handler under nested TestHint and then find it easily on the torture
side.

Adds the logic to render TestHint only when the test mode is enabled
in order to be able to put independent TestHints in other places than
the TestConnectionInfo component.

- old toolbox actions
- chat command processor
- room subject handling

Be explciit about the appearance we desire, since each mounted StaturBar
component will override the existing values. In this case, the problem was
caused because the default on iOS is dark, whereas it's light on Android.

Set it to light so it works consistently across both, which is what we want.

It's too sensitive and most of the time I cannot perform an onPress. In
contrast, the builtin/default/standard onPress is noticeably more
forgiving. While we fix the sensitivity of "pinch to zoom", don't use
its onPress unless absolutely necessary i.e. use it only for desktop
streams.

Zoltan Bettenbuk suggested the following:

         const state = getState();

          if (desiredTypes.length === 0) {
 -            const { audio, video } = state['features/base/media'];
 -
 -            audio.muted || desiredTypes.push(MEDIA_TYPE.AUDIO);
 -            video.muted || desiredTypes.push(MEDIA_TYPE.VIDEO);
 +            const startAudioOnly = getPropertyValue(state, 'startAudioOnly');
 +            const startWithAudioMuted
 +                = getPropertyValue(state, 'startWithAudioMuted');
 +            const startWithVideoMuted
 +                = getPropertyValue(state, 'startWithVideoMuted');
 +
 +            if (!startWithAudioMuted) {
 +                desiredTypes.push(MEDIA_TYPE.AUDIO);
 +            }
 +            if (!startAudioOnly && !startWithVideoMuted) {
 +                desiredTypes.push(MEDIA_TYPE.VIDEO);
 +            }
          }

          const availableTypes

The final commit is really a different implementation of the same idea
but takes into account that the state of base/media already contains the
intent of the URL and notices the delay in the realization of the
background app state.

Additionally, unbreaks one more case where setAudioOnly is incorrectly
dispatched on CONFERENCE_LEFT or CONFERENCE_FAILED and, consequently,
overrides the intent of the URL.