* fix(RTC): Remove support for plan-b SDP.
Since unified plan mode becomes the default mode, so does multi-stream mode.

* squash: Remove plan-b unit tests and fix comments

* squash: address review comments

Currently, the client doesn't attempt to re-establish bridge WS when the connection is closed by the remote end with a code 1001. We have noticed that Cloudflare terminates the WS with the same error code when it recycles its proxies. When that happens, client ends up not having a bridge channel which can result quality issues.
Client now tries to re-establish connection when there are remote endpoints in the call.

Endpoint based receiver constraints and other endpoint based bridge signaling messages are no longer supported by latest JVB after the switch to source-name signaling.
Rename method names 'sendNewReceiverVideoConstraintsMessage'->'sendReceiverVideoConstraintsMessage', 'setNewReceiverVideoConstraints'->'setReceiverVideoConstraints'

* Remove support for legacy endpoint based signaling and make source-name signaling as the only signaling mode. The legacy screensharing mode will no longer be supported. The client will still be able to process remote presence sent in the old format to support interop with very old mobile clients and jigasi that do not support source-name signaling.
* remove code related to presenter mode.

They have been deprecated and their valued can no longer be changed from
the default after M103.

Ref: https://groups.google.com/u/0/g/discuss-webrtc/c/2l7jWgreYpw?pli=1

This fixes an issue where the receiver constraints and video type messages are sent on the bridge channel only the first time the ws conn gets re-established.

* feat(multi-stream-support) Add TrackStreamingStatus class
update JitsiRemoteTrack to init and dispose TrackStreamingStatus
stop emitting LASTN_ENDPOINT_CHANGED event when source name signaling is enabled
convert TrackStreamingStatus class to typescript

* rename methods and use TrackStreamingStatus enum

* update jdocs for JitsiConferenceEvents.FORWARDED_SOURCES_CHANGED

The encodings for local video tracks are confiugured based on the SenderVideoConstraintsV2 constraints received from the bridge. The constraints are sourceName based. Also ignore enableLayerSuspension flag since it has been deprecated and layer suspension has been enabled by default. Also having it off makes screensharing on Chrome in unified plan not work as expected.

Sends the source name to video type mapping to the jvb
in a new bridge channel message.

It makes more sense to call it pcConfig since it is the RTCConfiguration object passed to the WebRTC peerconnection.

This lets the bridge adjust the bitrate allocation for this source so that layers with higher fps are prioritized over layers with higher resolution.
As a result, endpoints with restricted downlink will receive a high fps low resolution share as opposed to a high resolution low fps screenshare.

remove legacy APIs which are not even supported anymore

Provide a method for changing the capture fps for desktop tracks during the call. These changes to the lib are needed for making it configurable from the UI.

Set the initial video type state to NONE to cover cases when the endpoint joins video muted.

This can be controlled through the config.js  option 'enableUnifiedOnChrome'.

When a msid attribute is missing in the 'a=ssrc' line, use the local endpoint id as an indentifier. Move this generation logic to LocalSdpMunger. Also suppress notifying Jicfo of a ssrc change on Firefox when the change is a result of the media being suspended on the jvb connection.

Do not send old format constraints if no constraints are set before the channel is initialized.

Use the new Colibri message "EndpointStats" for broadcasting the local stats. The bridge then will be able to filter the endpoint stats and send them only to the interested parties instead of broadcasting it to all the endpoints in the call.

Stop using the legacy pc constraints that are no longer wired up to WebRTC.

* fix(TPC): Configure degradation preference in RTCRtpSendParameters.
Properly configure degradation preference on RTCRtpSendParameters instead of RTCRtpEncodingParameters. Fixes https://github.com/jitsi/lib-jitsi-meet/issues/1510.

* feat(JingleSessionPC): Remove ssrcs from remote desc when a user leaves.
Remove the ssrcs (associated with remote sources) from the remote desc along with the removal of the remote tracks when an endpoint leaves the call. The source-remove signaling message from Jicofo will no longer be needed in this case and can be dropped.

* Added video mute participant

* Trigger mute event

* Optimized mute type checks

* Fixed event name

* Fixed some linter issues

* Fixed more linter issues

* And even more linter issues fixed

* And more linter fixes

* Added media type to analytics event

Translate the 'LastNChangedEvent', 'SelectedEndpointsChangedEvent' and 'ReceiverVideoConstraint' messages into the new 'ReceiverVideoConstraints' message that invokes the new bandwidth allocation algorithm in the bridge that is described here - https://github.com/jitsi/jitsi-videobridge/blob/master/doc/allocation.md. useNewBandwidthAllocationStrategy=true in config.js will invoke the translation in the client.

Fire PERMISSION_PROMPT_IS_SHOWN when none of the devices have a label
Fire a new SLOW_GET_USER_MEDIA event if the timeout for getUserMedia is exceeded

Update JitsiMeetJS.createLocalTracks to include the options for firing the above events
in the provided options argument. Deprecate the firePermissionPromptIsShownEvent flag in
method's signature

All the send video constraints for the client, i.e., what simulcast streams will be enabled based on constraints received on the bridge channel, will be handled by the SendVideoController class.
The receive video constraints like lastN, selectEndpoints and receive video resolution will be handled by the ReceiveVideoController class.

"Pinned" endpoints are deprecated, use "selected" instead.

Remove redundant _channelOpen flag from RTC and rely on the channel's isOpen() getter instead.
This fixes an error throw when the _channelOpen flag was not updated while the channel's been
closed by the bridge.

Delays e2e encryption initialization until any encryption key is set.
Recreates peerconnections in order to enable insertable streams
only if the e2ee is used. This is to avoid bug around insertable streams
which may cause audio issue when the main JavaScript thread is loaded:

https://bugs.chromium.org/p/chromium/issues/detail?id=1103280

This is useful for testing insertable streams related issues.