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

- Use getDisplayMedia on browsers where it is supported.
- desktopSharingChromeDisabled and desktopSharingFirefoxDisabled will no longer be supported.

Refactors the way send/receive video constraints are managed and puts the high level
logic in a separate module. See QualityController.js for high level overview on how
the constraints are managed now.

Adds events to JitsiConference fired whenever it starts new jvb/p2p session.

Adds event to JingleSessionPC.js when remote party signals receive max frame height.
Also adds signaling of the local recv preference for the p2p mode(only existed for JVB).

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

When screensharing is stopped on FF from the sharing indicator (available in FF nightly), we are currently not detecting it.
Firefox fires a track 'ended' event as opposed to Chrome which fires a mediastream 'inactive' event as well.

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

Make sure we inject the encoding function on RTCRtpsenders when tracks are replaced on the peerconnection.
Update the MediaStreamTrack on the JitsiLocalTrack when effects are applied or removed so that
we can find the RTCRtpSender using the MediaStreamTrack

Standard audio constraints need to be passed to gUM for audio input device selection
to work properly on Safari.
Safari doesn't support permissions query, add a workaround for that.

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

MediaStreamTrack getConstraints on Safari returns an empty object.
Enable device selection on Safari.

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.

Some devies may not be able to satisfy it and gUM will fail. Tested with a
crappy old camera which can only do VGA resolution at 4/3 aspect ratio.

Co-Authored-By: Saúl Ibarra Corretgé <s@saghul.net>

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

Overconstrainederror occurs when calling gum with "exact"
when on URLs with a hash. To get around this, remove
"exact". Add handling for specified device not being
found, as we can no longer rely on "exact". This
still leaves open the possibility of the wrong
camera being accessed.

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.

We had several reports that googSuspendBelowMinBitrate misbehaves, we had been running for a while with that disabled for the bridge, but it was causing problems and for p2p.

React Native also supports it now.

If it's good enough for Google Meet it's good enough for us :-)