...and remove duplication.

...when starting without video.

The app would crash in setSenderVideoConstraint,
because the RTP encoding are not available on Safari
until sLD/sRD cycle is performed.

Handle the promise returned by RTCRtpSender.setParameters.

(cherry picked from commit a14b3c80ae)

When the video sender constraint changes in the p2p case when the remote user switches between stage/tile view,
get a downsampled video of the original 720p stream instead of requesting the camera for a new stream with the lower resolution.
Fixes https://github.com/jitsi/jitsi-meet/issues/7267

* feat: Apply max bitrates on video sender
Add the ability to control the max bitrates on the video sender through a config.js videoQuality setting.

* ref: Use '_' prefix only for internal methods

Moves the logics which deal with JitsiConference events to a separate module.

* feat: use getSynchronizationSources on the receiver for remote audio levels
Use getSynchronizationSources if it is supported, fallback to using getStats otherwise.
* feat/ref: Use the local audio levels from LocalStatsCollector
When using getSynchronizationSources, use the audio levels from LocalStatsCollector for NoAudioSignalDetection.js
Remove obsolete code - TalkMutedDetection feature using audio levels is not used anymore

* fix: Takes disabled encodings into account when calculating local resolution.
* feat: Adds a new event that's triggered when the max enabled resolution changes.
* feat: Broadcasts the max enabled resolution value along with other stats.

It's not yet supported, so assume success.

* feat: Set degradation preference on video senders
Use 'maintain-framerate' for camera tracks and 'maintain-resolution' for desktop tracks

* ref: apply cached video contraints and degradation preference on unmute
Since the sender encodings are available only after the renegotiation is complete (on chrome/safari), constraints/preferences have to be applied after renegotiation is complete.

We switched to using replaceTrack for Firefox and Safari in the unified-plan rewrite

Remove unused code, we always use replaceTrack in unified plan

This behavior got altered when we correctly update the reference we keep of MediaStreamTrack in JitsiLocalTrack when effects are applied

Add RFC 4588 to the list of advertised features on Firefox.
Use RtxModifier only for cases when simulcast is achieved through SDP munging
This will ensure that RTX is negotiated whenever it is offered by the browser.

In preparation for turning on RTX on Firefox: add only the primary ssrcs to the SIM group if FID groups are present

This will make sure we get 30 fps for screenshare on p2p connections

MediaStreamTrack.getSettings is not implemented.

* feat(video-quality): control the sender resolution based on video quality settings

* fix(video-quality): Apply the settings on newly created p2p/jvb jingle sessions
If a p2p/jvb session is not present when setSenderVideoConstraint is called,
make sure the settings are applied when they are created

Make sure we don't have a=simulcast lines on the sendonly m-lines in the remote description

Get rid of the experimental flag for simulcast support, update js-utils for detecting Edge on Android

Trigger renegotiation only for plan-b when tracks are muted or unmuted

Enabled desktop sharing and discontinue support for Safari versions prior to 12.1, i.e., the ones with no VP8 support

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

Switch to using ontrack for remote tracks, re-use mids/transceivers when remote sources are removed and added.

Trigger renegotation only when negotiationneeded event is fired on the browser.
Do not disable simulcast for screensharing in unified plan.
Fix the order of the simulcast streams for Firefox

Calls to insertDTMF will stop any tone
playing in progress. Prevent such by
checking the tonebuffer for any tones
in play and queue tone playing if
any tones are in play.

Enable/disable this feature using 'capScreenshareBitrate' testing flag in config.js and send analytics
events to Amplitude to indicate which type of screensharing is enabled.

Moves sendTones implementation to TraceablePeerConnection. It will be
responsible for creating/storing a DTMFSender. JitsiConference will
use the currently active TraceablePeerConnection to send the tones.

This fixes a bug where DTMF tones can not be sent after
JingleSessionPC/TraceablePeerConnection instance changes.
The JitsiDTMFManager instance was referencing invalid PeerConnection.

In TraceablePeerConnection: we're no longer injecting a recvonly SSRC
when the local video track is muted, so it's normal that there is no
SSRC found in the local SDP when it's muted.

About RTPStatsCollector: at the time of adding this log statement a case
was missed when local audio track could be replaced in the P2P
connection when a new audio device is selected.

Starting in Chrome 71, tracks without a stream are
given the msid "-", which in plan b incorrectly
triggers an onaddstream even with a default local
stream.

Until M69 Chrome used to consistently emit "onstreamadded" when
audio/video stream is added for the first time and then emit track
events only if the stream is modified afterwards (video track replaced).

However it looks like now it can first emit "onstreamadded" and then
additional "ontrackadded" for the MediaStreamTrack that was already
included in the MediaStream signalled by the "onstremadded" event. I
have not managed to figure out what is causing this and the only
difference in the SDP is the fact that the remote peer (JVB) includes
IPv6 candidates. Anyway it doesn't hurt to have such a safeguard.

Just skip it in such environments, such as React Native.

This function helps simplify the code when handling browsers that are pretty
much Chrome in disguise.

Keeps it consistent with the previous implementation.

It's 2018 after all...

* Change layer suspension to use parameters in RTPSender

We no longer suspend unused simulcast layers via a bandwidth cap in the
SDP, instead we'll use the new parameters in RTPSender to enable and
disable streams explicitly.  The main advantage here is the RTPSender
method ramps up immediately when we re-enable the layers (as opposed to
the SDP bandwidth cap which took 30+ seconds).

* Fix linter issues