Check for source updates and notify the peer of any new sources after every renegotiation cycle. This fixes issues where source changes are not detected if any other task that requires a renegotiation is scheduled between replaceTrack and a negotiationneeded event.

Fixes a bug where the remote video freezes if the remote user does an ICE restart using session-terminate. In this case, a new SSRC is assigned to the remote source which will have the same source-name.

Pull initial offer/answer tasks out of the modification queue and execute them right away. Only track and codec related operations that necessitate a renegotiation cycle need to be pushed to the modification queue. The queue execution is paused until the session is established. This avoids track operations being executed before the session is established. This fixes an issue seen in p2p connections where sources of the initiator are not signaled to the remote since the tracks are added while the initiator is waiting for a session-accept from the peer.

Also add all the orphan jvb tracks to the conference when the call switches over from p2p to jvb.

When configureSenderVideoEncodings task is pushed to the modification queue, there might not be a setParameters call in progress and this new one will not get chanined to any promise. However, when the task finally is executed, there is a chance for another setParameters method execution to be in progress and can result in setParameters call failing. Also, these extra steps to ensure that the sender encodings are correctly encoded are no longer needed since with multi-stream mode, we do not change the source video type and the previous encodings config will still be valid.

* feat: Add initial-last-n to jingle if config.channelLastN is set.

* Also add initial-last-n to transport-accept.

This fixes an issue where p2p clients (with different codec preferences) fail to decode video because the negotiated codecs are removed from the supported codecs list after the media session is established. The codec preferences will be applied when the first offer/answer is created.

* fix(TPC) Disable media instead of changing dir for p2p->jvb switch.
Resume or suspend the media on the jvb peerconnection by changing the RTCRtpEncodingParamters.active state instead of changing the direction on the transceiver. This avoids the needs to start a O/A renegotiation cycle for these operations. The media direction will be changed only for p2p lastn=0 case since video needs to be disabled on both the sender and the peer for p2p lastn=0 case.

* Address review comments

* Disable media after adding source while media is suspended on the jvb connection. Default 'active' state for stream encodings after the source is added is 'true'.

* Wait for all the promises to be settled before returning

* fix(SignalingLayer) Update SSRC owners on leave.
Update the SSRC owners in the following cases:
1. When a remote endpoint leaves the call.
2. When a source-remove is received.
3. When a source is remapped (with ssrc-rewriting enabled).
Create the remote track even if presence is not yet received. The ssrc owner check prevents the client from creating a dummy track when the call switches over from p2p to jvb when the last remote endpoint leaves the call.

* ref(SignalingLayer) alpha sort methods.
Clean up unused methods, _findEndpointSourceInfoForMediaType is not used anymore.

* squash: Address review comments.

When the application doesn't set receiver constraints, generate default constraints in the source-name mode.
Cleanup code related to the endpoint based video constraint handling for p2p connection.

Simulcast for SS is always on in unified plan mode, the lower spatial resolution streams are turned off for low fps sharing.

Always initiate a sRD->cA->sLD cycle since renegotiation fails in the following scenario.
In a p2p call when channelLastN=0, the direction on the video tranceiver is set to'inactive'.
At this point, if the user unmutes, the track is replaced on the video sender.
If a cO->sLD->sRD is triggered, the browser adds a third m-line which isn't expected and possibly is a bug. All renegotiations fail as a result.
However, the browser does not add a third m-line in the answer it generates and renegotiation succeeds.

1. Checks peer's preferred codec in p2p case. Mobile and web have different preferred codecs.
2. Log an error message when the preferred codec is not offered by JVB.
3. Clean up code related to deprecated config.js settings 'preferH264' and 'disableH264'.
4. Refactor the codec selection logic so that correct codec is picked.

* 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.

The candidates are not necessary when we use jvb.

Instead of Jicofo signaling all the remote sources available in the call, the bridge now signals only a limited set of SSRCs and then rewrites the SSRC on the outgoing media streams. The SSRC mapping is done based on the sources requested by the clients through the receiver constraints. This limits the number of m-lines in the remote/local SDPs on the client and therefore results in better performance in large calls.

* Handle source remapping messages from bridge
* Added track_owner_changed events
* don't process an invalid rtx ssrc.
* keep track of remote ssrcs, only renegotiate on new ones.
* Change source name on remote track on ssrc remapping.
* Don't remove tracks on member leave.
* Remove (orphaned) tracks on session terminated.
* Use serial number (per media type) to create msid attribute.
* Update videoType on remapping.

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

* fix(codec-selection) Munge all related m-lines for multi-stream.
Munge all the video m-lines to apply the preferred codec settings in multi-stream mode.

* fix(TPC) Cache transceiver mids for all local video tracks.
There will be multiple video tracks in multi-stream, we need to cache the mids for all the the associated transceivers.

* fix(sender-constraints) Do not apply sender constraints if value hasn't changed for a given source.

* fix(TPC) Configure the direction correctly for all m-lines.
Ignore negotiationneeded events for p2p to avoid going into a renegotiation loop.

* squash: Address review comments.

Fixes cases where SS fails in multi-stream mode with p2p->jvb->p2p switching.

Avoid needing an external dependency.

Fixes cases where SS stream is not being sent when p2p->jvb switch happens.

When an answer is received from the p2p peer, only set remote description instead of calling the full renegotiation cycle. Also, always initiate a sRD->cA->sLD cycle when adding remote sources irrespective of whether the local endpoint is an initiator or responder for the p2p connection. This lets us remove the hacks added for Chromium (unified-plan) bugs related to video not rendering in p2p cases.

Since Track effects and mute/unmute operations use the same flow, i.e., removing/adding the track from the RTCPeerConnection but not from TPC, make the names of the methods involved more generic.

With just source-name enabled, set the source name of the replaced track before configuring the encodings, this fixes an issues where the sender constraints are not applied on the p2p connection because the source name is undefined.

* fix(video-quality) Update frame heights in content-modify for p2p.
When the user changes the preferred video quality settings from the UI, update the frame height values in content-modify for p2p connection when source-name signaling is enabled.

* fix(multi-stream) Send presence for desktop track before signaling when it is the first track to be added to the conference.
Also do not suppress renegotiation for desktop track on p2p since the browser doesn't fire negotiation needed event.

* squash: fix build

* squash: fix linter issues

* squash: add comment.

* fix(multi-stream) add new m-line when remote adds a second video source in p2p.
A new m-line needs to be added in the remote description when a new secondary video source is signaled by the peer.

* fix(TPC) Suppress lower layers only for screenshare tracks.
With multi-stream support enabled, an extra check for videoType for local track is needed to dtermine if the lower layers need to be suppressed.

* fix(TPC) Mark the direction inactive on inactive media connection.
If a new secondary video source is added on the jvb connection while p2p is active, make sure the direction is set to inactive on the jvb connection, so that no media is being sent out on the jvb connection.

* squash: Address review comments.

We do not want the client to re-use the inactive transceivers that are associated with m-lines for removed remote tracks. Rejecting a m-line on source-remove clears it from the list of available transceivers.

If there are more than one video track at pc creation time, add them sequencially to avoid renegotiation loop.

* fix(multi-stream-support) Support muting of desktop track.

* fix(multi-stream) Always initiate responder renegotiation even for p2p.
This is needed since the new m-line is always added to the remote description.

* fix(multi-stream) Support multi-stream only on Unfied plan endpoints.

* fix(multi-stream) Advertise source-name signaling to Jicofo when supported.

* fix(JitsiLocalTrack): Remove unnecessary reject.

* fix: add the correct source name attribute for the second video track.

* squash: Address review comments.

In P2P and unified mode, Chrome does not render the media if an SSRC is removed and the same one is added back (happens when the sender is camera muted->starts SS->stops SS->turns camera on). That is why SSRC was not being removed. However, mobile endpoints that are running in plan-b generate a new SSRC when the client switches between camera and screenshare. This will cause issues on a p2p receiver that is running in unified mode. Fixes https://github.com/jitsi/jitsi-meet/issues/11010.

Recycling the m-line by rejecting it and then re-using is causing issues where sometimes the track addition fails. When a new ssrc is added to an m-line that was rejected and port is changed back to the default port, sometimes the remote sdp returned by browser wouldn't contain the newly added ssrcs and the track addition fails as a result.
Error: No SSRC lines found in remote SDP for remote stream[msid=854882f8-audio-1,type=audio]
    at Ca._remoteTrackAdded (https://web-cdn.jitsi.net/meetjitsi_5885.2601/libs/lib-jitsi-meet.min.js?v=5885.2601:2:439103)
    at Ca._usesUnifiedPlan.onTrack (https://web-cdn.jitsi.net/meetjitsi_5885.2601/libs/lib-jitsi-meet.min.js?v=5885.2601:2:432207)
    at RTCPeerConnection.r (https://web-cdn.jitsi.net/meetjitsi_5885.2601/libs/lib-jitsi-meet.min.js?v=5885.2601:2:680736)
.

It's possible we get sender constraint messages while operations to
change the direction in the JVB session are in progress so we currently
have no predictable way to properly suspend video without races.

Since this will be solved when we move to transceivers, this is a
compromise we are making.

Fix having duplicated audio due to the JVB connection being re-activated
once the sender constraints change.

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.

When a user leaves, the ssrcs associated with the ep are removed from the remote description and a renegotiation is forced. The browser then fires 'removetrack' event on the associated MediaStream when sRD is called with ssrcs removed. The remote track is then disposed of in the event handler. Therefore, there is no need to delete the tracks at the TPC level before renegotiation. This also prevents the 'Removed track not found for stream' events from showing up in the browser console log.

* ref(JingleSession) Recycle m-lines by rejecting them on source removal.
By rejecting the m-lines on source removal (setting the port to 0 on the associated m-line), m-lines can be recycled for new sources instead of appending new ones.

* chore(deps) update sdp-interop@latest.

* fix(RTC): fixed typo in function name

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

* fixed typos