Wrong check for unsupported getDisplayMedia when starting screen sharing will cause the app to never fallback to getUserMedia flow. This breaks screen sharing for all old electron clients that do not support getDisplayMedia.

Detect if gDM support has been enabled and fallback to the previous gUM
flow otherwise.

- Lower logger level to warning
- Use nested conditions

If the enclosing Jitsi Meet app declares gDM in Electron is supported,
ignore the `electronUseGetDisplayMedia` config flag and use the gDM
flow. This facilitates having backwards compatibility since the Electron
app won't know if the deployment it's about to join has the gDM flow
support or not.

Don't show the misleading "user cancelled" error, there are corner cases
in which a different error can be manifested.

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