* feat(ScreenObtainer): add more control over screen obtainer

* fix(ScreenObtainer): fix constraints to select a preferential display surface

* fix(ScreenObtainer): remove Safari version check for displaySurface

* fix(ScreenObtainer): move all settings under screenShareSettings

contentHint needs to be set to 'motion' for high fps SS and 'detail' otherwise. Fixes https://github.com/jitsi/lib-jitsi-meet/issues/2298.

Request higher capture resolutions when desktopSharingFrameRate is not defined in config.js.

It was behind a testing flag setScreenSharingResolutionConstraints.

Allow users to seamlessly switch which tab they are sharing without having to stop the current share and select a new tab again. This is supported on Chrome 107 onwards.

The hack for making Chrome capture the highest resolution possible for desktop track breaks high fps screen capture.

* feat: Add an option to set bogus resolution constraints for getDisplayMedia.

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.

* fix: high CPU on Chrome with low fps screen sharing

It turns out that if 5 fps is set on the track constraints,
Chrome will capture the original video in 30 fps and only
further down the pipeline will downsample it to 5 fps.
This results in very high CPU usage. Specify max FPS in
getDisplayMedia to fix the problem.

Getting rid of track.applyConstraints should also fix another
issue on Firefox where it reports 0x0 screen size after this call.

* ref(RTCUtils): remove trackOptions

* remove extra &&

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

Both of the cases where user clicks cancel and when screen recording
permissions were not granted at the OS level are almost the same,
except for a small difference in the error.message.

This was only tested on Chrome 85.0.4183.121/Mac OS 10.15.6

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

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

Supported since Firefox 66.

Chrome 71 does not support inline installs, but has navigator.getDisplayMedia
behind a flag. Support this case.

We now use PeerConnection promise-based APIs, which were introduced in M51.

Keeps it consistent with the previous implementation.

Get rid of all wrappers and use navigator.mediaDevices.getUserMedia, since all
supported platforms have it by now.

Also use the unprefixed versions of WebRTC APIs.

* Enables adapter for edge.

We were not filtering correctly all unsupported iceServers and an error is thrown and no connection is established.

* Enable desktop sharing for Edge.

Currently when replacing video track with desktop sharing one, doesn't work because of: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17528460/
If Edge user joins first and enables desktop sharing it will work when others join. Tried also to use replaceTrack/setTrack as a workaround, but again we hit an error, this time InvalidAccessError.

* Adds the helper function usesAdapter in BrowserCaps.

When cancelling the prompt to install the extension, instead of
treating it as a generic error treat is as the cancel extension
error. This allows existing logic to trigger that will not show
an error message on cancel.

* fix(SS): Set min and max frame rate to 5

* fix(SS): Set min and max frame rate for the new GUM flow.

* feat(ss_framerate): Add config option for min/max frame rate.

* doc(RTCUtils): Fix params format.

* fix(SS_framerate): Don't pass undefined constraints.

* fix(SS_constraints): Handle  chromeMediaSourceId === undefined.

* log: Logs when analytics are disposed, drops events early.

* fix: Adds a missing parameter to a function call.

In order to include browser capabilities in RTCBrowserType I needed to
refactor RTCBrowserType.