* feat(conference): Enable forced reload of client on bridge failure.
Force the client to reload when the bridge that is handling the media goes down.
This mitigates issues seen on the bridge because of a client re-joining the call with the same endpointId, BWE issues, etc.
This behavior is configurable through 'enableForcedReload' setting in config.js.
The client skips the pre-join page when the page reloads.

* squash: refactor the restart logic.

* squash: fix description

* squash: dispatch conferenceWillLeave action before reload.

Co-authored-by: Saúl Ibarra Corretgé <saghul@jitsi.org>
Co-authored-by: zycwind <391321232@qq.com>

They also need to be applied when changing conferences.

Also, use the configured resolution to set it as the max received frame size.

Skip processing any other participant updates.

There are occasions when role to moderator can change a little bit after joining the room, and initial try to set subject will silently be ignored if not moderator.

The lobby feature adds the possibility to lock a meeting and only allow people in after virtually knocking and going through formal approval

* ref(Filmstrip): Optimize resizes.

* fix(thumbnails): resize.

* fix(thumbnails): Issue with height 0, width 0.

* doc(Filmstrip): Improve JSDoc.

Move call to reloadNow() on CONNECTION_FAILED to
the ./features/app/middleware to avoid importing higher order feature
from the lower level one.

- Adds the ability to share video as a "PiP" when screenshare is in progress.
- Add a method for creating a local presenter track.
- Make sure isLocalVideoTrackMuted returns the correct mute state when only screenshare is present.
- Make sure we get the updated window size of the window being shared before painting it on the canvas.
- Make sure we check if the shared window has been resized

React Native doesn't define __filename nor __dirname so do it artisanally. In
addition, this helps with centralizing the configuration passed to loggers.

This refactors all handling of audio-only and last N to 2 features in preparation
for "low bandwidth mode".

The main motivation to do this is that lastN is a "global" setting so it helps
to have all processing for it in a single place.

When a participant is pinned in the UI we then proceed to mark it as selected on
the JVB. This will make the participant part of the last N set and will receive
the highest (or configured highest) video quality.

Pinning a participant at the JVB level just makes sure it will be part of the
last N set.

Since only one participant can be pinned in the UI, there is no point in pinning
it at the JVB level, since selecting it already achieved the same result.

This PR changes the logic for connecting / disconnecting conferences. Instead of
doing it in mount / unmount events from the Conference component, it moves the
logic to the appNavigatee action.

This fixes a regression introduced in 774c5ecd when trying to make sure the
conference terminated event is always sent.

By moving the logic to appNavigate we no longer depend on side-effects for
connecting / disconnecting, and the code should be more maintainable moving
forward.

An improvement to this is the concept of sessions, which, while not tackled
here, was taken into consideration.

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

Dominant speaker events can trigger local participant updates
without a display name. Do not update the name unless there
is an explicit update in the action.

Analytics is erroring when unpinning because the logged
event sends null for the objectId. The objectId should
be the id of the person getting unpinned.

Move away from middleware and instead update video quality
when the selected video quality updates in redux. This also
lead to removing of automatically exiting audio only because
with the change it's not so readily possible to tell if the
user switched off audio only by re-selecting the already
preferred video quality. Removing this automagic removed
some additional checking done for mobile.

The internal max will be used for tile view. Whatever the
user has set for preferred video quality, the internal
maximum will be respected. This allows for the case where
the user prefers high definition video, but in tile view
it only makes sense to send low definition; ux wise the
user is allowed to continue messing with the video quality
slider.

- "preferred" is being appended because in tile view there is a
  concept of what the user prefers to be the maximum video quality
  but there is also a maximum respected internall. For example,
  the user may prefer HD, but in tile view the tiles may be small
  so internall the preferred would be set to LD.
- "receive" is being renamed to "receiver" to be consistent with
  the naming in lib-jitsi-meet.

* 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

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.

Makes sure that whenever a conference is left or switched, the local
participant's id will be equal to the default value.

The problem fixed by this commit is a situation where the local
participant may end up sharing the same ID with it's "ghost" when
rejoining a disconnected conference. The most important and easiest to
hit case is when the conference is left after the CONFERENCE_FAILED
event.

Another rare and harder to encounter in the real world issue is
where CONFERENCE_LEFT may come with the delay due to it's asynchronous
nature. The step by step scenario is as follows: trying to leave a
conference, but the network is not doing well, so it takes time,
requests are timing out. After getting back to the welcome page the
the CONFERENCE_LEFT has not arrived yet. The same conference is joined
again and the load config may timeout, but it will be read from the
cache. Now the network gets better and conference is joining which
results in our ghost participant added to the redux state. At this point
there's the root issue: two participants with the same id, because the
local one was neither cleared nor set to the new one yet
(PARTICIPANT_JOINED come, before CONFERENCE_JOINED where we adjust the
id). Then comes CONFERENCE_JOINED and we try to update our local id.
We're updating the ID of both ghost and local participant. It could be
also that the delayed CONFERENCE_LEFT comes for the old conference, but
it's too late and it would update the id for both participants.

The approach here reasons that the ID of the local participant
may be reset as soon as the local participant and, respectively, her ID
is no longer involved in a recoverable JitsiConference of interest to
the user and, consequently, the app.

Co-authored-by: Pawel Domas <pawel.domas@jitsi.org>
Co-authored-by: Lyubo Marinov <lmarinov@atlassian.com>

Because a conference can fail before or after it's joined it must be
"left" in order to release any allocated resources like peerconnections,
tracks and all the other things.

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.

This reverts commit 88325aeef2.
Turns out a conference with a password triggers a failed conference
join. It's going to be tricky to decipher when to do actual
cleanup, and where to shove that code, so reverting is easier for
now.

Destroy local tracks and also destroy large video so the
user does not wonder why camera (and mic) are still enabled
even though hangup has been pressed.