Accessibility: keyboard navigation on the toolbar (Context menu)

The latter supports tree-shaking and we don't need to embed the whole
500KB of lodash.

* fix(flags): Don't assume ssrc-rewriting enabled by default.

* chore(deps): update latest@lib-jitsi-meet.
https://github.com/jitsi/lib-jitsi-meet/compare/v1796.0.0+d1333434...v1802.0.0+49ff6eb4

* feat: Enable ssrc-rewriting by default.

* chore(deps): Update lib-jitsi-meet.

Since plan-b mode will no longer be supported, check for unified plan support is not needed anymore.

Remove unnecessary @ts-ignores
Use @ts-expect-error instead of @ts-ignore for external dependencies

Fix some errors. Remove @ts-ignores
Convert some files to TS
Remove some eslint-disables

Always enable unified plan support on Chromium endpoints.

- redesign deeplinking mobile page, desktop page and dial in number page
- now dial in number page is an entry point in app.bundle.

Use a fixed set of remote tracks for a call based on the ssrc-limit set in jvb config. When this feature is enabled, JVB will signal the audio and video SSRCs and their owner/endpoint info using a bridge channel message. For audio, the mappings are determined based on the energy rankings on the audio sources present in the call and for video, the mappings are calculated based on the video sources the client requests through the video receiver constraints.
Remote tracks are then created/remapped by the client based on these mappings.

* Added track_owner_changed action
* Skip track-based large-video selection in rewriting mode.
* Register OWNER_CHANGED handler at track level.
* feat(participants) Add source info to participants in redux.
With ssrc-rewriting, the receiver constraints need to be generated using the source info received in presence. Currently they are generated from the track info in redux but with ssrc-rewriting, remote sources are not signaled and therefore created until they are being requested through receiver constraints.

Co-authored-by: James A <jqdrqgnq@users.noreply.github.com>

We don't plan to send both (camera and screen) streams at once, but we
do plan to align with web and have both streams at the same time, with
the camera being muted when we start screen sharing.

Remove unnecessary @ts-ignores
Remove unnecessary eslint-disable

* fix(connection-status): remove unused participant connectionStatus.
Always use trackStreamingStatus now that legacy endpoint based signaling has been removed.

* remove the check for source-name signaling.
Default to source-name signaling always.

* Remove the check for multi-stream mode.
Make that the default mode and remove the support for legacy SS mode.

* Remove presenter mode.

* update latest@lib-jitsi-meet

Mobile does not do multiple local video streams for performance reasons,
so avoid creating the local fake participant.

WIP

* fix(multi-stream) update selector to find ss track by videoType or mediaType

* ref(multi-stream) move fake ss creation logic and support video type changed

* refactor(multi-stream) decouple sending and receiving multiple screenshare streams

* fix(multi-stream) fix receiver constraints with signaling and without multi-stream

* fix(mutli-stream) ensure plan b original SS thumbnail displays avatar

* fix(multi-stream) show fake SS for plan b sender

* refactor(multi-stream) poc for moving SS creation to state listener

* remove reference to fake SS creation

* fix lint errors

* rename to virtual screenshare participants

* fix minor bugs

* rename participant subscriber to specify web support only

Converted LoadConfigOverlay to a JitsiScreen component that right now is part of navigation as ConnectingPage, plus I
separated appNative and other actions into web and native.

* feat(multi-stream-support) Add screenshare as a second video track to the call.
This feature is behind a sendMultipleVideoStreams config.js flag. sourceNameSignaling flag also needs to enabled. Sending multiple tracks is currently supported only on endpoints running in unified plan mode. However, clients with source-name signaling enabled and running in plan-b can still receive multiple streams .

* squash: check if there is an existing track before adding camera/desktop

* squash: enable multi-stream only on unified plan endpoints.

* feat: Use source name based receiver constraints

* add sourceNameSignaling feature flag to config

* move source name specific variables into if block

* ensure sourceName is defined in constraints

* use source name for selectedSources

* use selector to find video track by participant id

* add selector to encapsulate logic to get track source name

* refactor getTrackSourceNameByMediaTypeAndParticipant selector

* rename variable

* move flags config into Feature Flags section

* do not set constraints for local large video

* rename prioritizedSources to onStageSources

* fix flow error

* refactor visibleRemoteTrackSourceNames to a constant

* use selector to get feature flags

* rename selector function

* fix flow error

* add selector for sourceNameSignaling feature flag

* Add configuration to disable removing raised hand on dominant speaker change

* Fix lint problem

* Avoid dispatching unnecessary action

* Fix lint problem

* feat(vpaas, recording): Show recording link to recording initiator

This applies only for jaas users for now but is easily extensible.
Changed the recording sharing icon according to ui design.

* fix(vpaas, recording): Guard for deployment info

They never worked on mobile and pose an impediment for makinf config.js more
future proof. Specially if we want to move to a non-executable form of
configuration.

For now all keys are whitelisted.

We try to load the configuration with every room change, even when there is no
room. There is a bad (corner) case: when we have no config cached (first boot or
wiped app data). In such case the user is trapped in an infinite loop because we
require the config to show the welcome page, oh well.

Pretend we have a configuration by creating the most minimal one to at least get
to the welcome page.

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