Fixes issue #1476
Alternative to PR #1487

* 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 colibri class name for the source name sender constraints changed from SenderVideoConstraintsV2 to SenderSourceConstraints.
The new format is {colibriClass: 'SenderSourceConstraints', sourceName: 'b6746083-v0', maxHeight: 180}

* feat(multi-stream-support) Adjust presence and videoType message.
Adjust the sourceInfo for all the available local tracks. Do not add handlers for videoType changes on the peer since the videoType doesn't change when multiple stream support is enabled.

* fix(presence) Send the presence in old format for backwards compat.
Send the presence messages in both the old and new format when source name signaling is enabled and sending multiple streams is disabled.

* fix(JitsiConference) Send the videoType bridge msg after mute/unmute op is complete.

* ref(multi-stream-support) Throw if a track is being replaced with a track of different videoType.
This is not supported in the multi sender enabled mode.

* Address review comments.

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.

* feat(multi-stream-support) Add the support for multiple local video streams.
This feature is behind 'sendMultipleVideoStreams' config.js flag and is currently supported only on clients running in Unified plan mode.

* squash: Use the track index from source name to find the matching transceiver on unmute.

* feat(multi-stream-support) Handle SDP munging for multiple local/remote streams/ep.
A new SDPSimulcast class is added for handling SDP munging for local and remote descriptions to handle multiple streams for both local and remote endpoints. This new class will be used only for unified plan implentation. The sdp-simucast npm package will be used for plan-b and deprecated later when all the clients switch to unified plan.

* fix(build) fix building with TS code

Use the Babel preset for the webpack bundle since Babel 7 already
understands TS and ts-loader uses tsc instead, which we configure
differently.

* squash: Add unit test and address review comments.

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

Fixes https://github.com/jitsi/jitsi-meet/issues/10754.

This fixes a regression introduced by the previous commit.

sLD is called immediately after createOffer/createAnswer, therefore the desc provided by createOffer/createAnswer can be directly passed to sLD without the need for converting it to unified plan format. This also fixes a warning seen on the browser console that says 'The description does not look like plan-b'.

The issue currently affects browsers based on Chromium 96.0.4664.110
including Brave, Chrome, Edge & Opera and Google Chrome 97.0.4692.56

* fix(RTC): fixed typo in function name

* fix(xmpp): codec renegotiation task needs to be queued

* fixed typos

* fix(tpc) disable ulpfec on chrome 96

* ref(tpc) add comment

Broken with previous commit 579a49.

This fixes an issue where a user is not able to unmute their video if the MediaStreamTrack associated with the camera stream returns a null value for the track height.

* Save track source name to JitsiRemoteTrack

* add feature flag checks. code review adjustments.

* eslint cleanup1

* eslint cleanup2

* fix: move sourceName declaration outside of if block.

Co-authored-by: Dennis Dowhy <ddowhy@gmail.com>
Co-authored-by: William Liang <wliang67@bloomberg.net>

This ensures that the source signaling is sent before the mute state is sent in presence. Jicofo relies on mute state from presence to check if the sender limit has been reached.

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

Add timestamp to all tracks, and display surface to screen sharing tracks

This fixes occasional failures of MuteTest.MuteAfterJoinCanShareAndUnmute torture test and also the case on Safari where user stopping the screenshare doesn't stop showing the screensharing indication on the thumbnail.

...to advertise track's muted state and the video type.

For now, if the source name signaling flag is enabled, both legacy and
new <SourceInfo> element will be used at the same time. This is to be
able to interoperate with legacy clients and start testing the new
format at the same time. Whenever possible <SourceInfo> will be used
as main source of truth with the fallback to legacy <audiomuted/>,
<videomuted/> and <videotype/> elements.

Fixes https://github.com/jitsi/jitsi-meet/issues/9988.

Instead rely on the 'negotiationneeded' event fired by the browser for JVB connection. This makes local source changes faster even if the modification queue is backed up.

* ref(TPC) Configure encodings in one go.
Configure the active state, maxBitrate and degradation preference in one go instead of configuring them separately.

* squash: Address review comments.

* squash: fix a comment.

* feat(CodecSelection) Disable VP9 on Safari.
Safari does not decode VP9 properly- https://bugs.webkit.org/show_bug.cgi?id=231071 and https://bugs.webkit.org/show_bug.cgi?id=231074.

* squash move VP9 support check to browser capabilities.

ChatRoom.setAudioMute and ChatRoom.setVideoMute are
not async, so no callbacks nor promises are necessary.

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

Log only the important events that we care about on the HTMLMediaElement that the remote tracks are attached to.

This fixes an issue where the bridge doesn't forward the HD stream from Firefox to other users in the call. The order of the ssrcs produced by the browser is from Highest resolution to lowest whereas the bridge assumes it to be from lowest to highest as is the case in Chrome and Safari.