The feature authentication affords recovery from CONFERENCE_FAILED
caused by AUTHENTICATION_REQUIRED. (Like the feature room-lock afforded
recovery from CONFERENCE_FAILED caused by PASSWORD_REQUIRED.)

Recently/as part of the work on taking into account the user defined by
JWT, the local participant (on mobile) started telling the remote
participants that he/she had the display name "me". Obviously, that's
incorrect. Do not store the default display name in redux. While it may
be argues that redux is the place for all states, base/participants and
the name property of Participant is not meant to be that display name
because that is being sent to remote participants, the default name
needs to be internationalized, etc. So it's better to not store the
default display name at this time at all because it's not used by mobile
anyway and Web already deals with remote participants who don't share
their display names.

fix(ContactListPanel): default display name

chore(deps): remove unused.

Adds application name to the initJitsiConference options.

A few occurrences of coding style/formatting which I noticed while
reviewing 'feat(eslint): Enable for non react files'. These are
definitely not all occurrences I could've noticed during the review
but... we're talking about files outside react/ anyway.

Will override email, display name and avatar URL with the values
provided in 'context.user' structure of the JWT token.

Settings will no longer be used to retrieve local display name,
email and avatar URL. Now those values will be obtained from
the /features/base/participants Redux state.

fix(jwt/middleware): use const for default name

fix: wrong default display name on web

ref(base/participants): remove getDisplayName functions

ref(jwt): do not accept unknown user fields

* doc: document disableH264 option

* [RN] Override disableH264 config option

We never want it disabled on mobile.

Instead of assuming the initial info dialog open should auto
close, explicitly call opening of the dialog with a flag for
auto closing. This better facilitates the auto close timeout
being set at any time.

The changes led to refactoring out state in the InfoDialogButton
in preference for always clearing the timeout instead of
first checking for interaction before clearing.

Delay showing the dialog until after joining the conference
instead of as soon as possible. This resolves a few issues.
One is the dialog displaying right before the permissions
overlay is shown. Another is that logically it does not
make sense to show the invite options when unable to invite.
It also sidesteps the initial react UI bootstrapping that
can cause race conditions with toolbar re-renders causing
misalignment. Lastly, it prepares prematurely for what I
assume will be changes for when the info dialog will
actually be shown automatically.

When _setLoggingConfig is invoked for the first time old and new config
are equal and _initLogging is not called. Currently, there is no way to
detect when the first time we call it is. We could use APP.logCollector
but it should go away at some point in the future.

Fallback to the room name otherwise. This allows us to have better entries in
the phone history.

Revert "[RN] Remove unnecessary source code" (commit
a3441030a3). But since the project file
needs to explicitly mention the CallKit and Intents framework, do not
use the semantic @import as that's confusing in the case.

CocoaPods has made some updates to the bundled resource files.

[RN] Fix setting full-screen when joining a conference

HIDE_DIALOG happens between WILL_JOIN and JOINED so get the joining conference
from the state instead of the action.

Never show the local participant in the large view unless it's the only
participant.

This fixes 2 issues:

- selecting the local participant when the camera permission wasn't granted
- selecting the other participant when they join a 1-1 call with video muted

Updates prosody config to have certificates for the auth. domain.

fix(defaultToolbarButtons): Fixes mute popup warning

Fixes exception when trying to unmute in the scenario, where someone else is sharing a video with you.

The certificates are generated on new install or upgrade and added to the current configuration and also to the trusted certificates on the local machine.