Stop using the legacy pc constraints that are no longer wired up to WebRTC.

Apple added getUserMedia support for WkWebview based browsers like chrome and Firefox on iOS 14.3. These browsers behave as Safari does on iOS. Therefore, extend the Safari checks to these webkit based browsers as well.

RTCUtils.enumerateDevices was being called earlier than the RTCUtils.init which assigned that function

Fire PERMISSION_PROMPT_IS_SHOWN when none of the devices have a label
Fire a new SLOW_GET_USER_MEDIA event if the timeout for getUserMedia is exceeded

Update JitsiMeetJS.createLocalTracks to include the options for firing the above events
in the provided options argument. Deprecate the firePermissionPromptIsShownEvent flag in
method's signature

It has been `true` for a very long time.

Cleanup some unused code after the bump.

The old stream needs to be released while keeping the tracks intact

Device IDs can change without triggering any event. In order to sync the
device IDs that  we store with the actual device IDs, we need to update
them every time when we call enumerate devices.

This error happens in getCurrentlyAvailableMediaDevices

* fix(safari): override min/max video constraints on safari
Override the constraints on Safari because of the following webkit bug.
https://bugs.webkit.org/show_bug.cgi?id=210932
Camera doesn't start on older macOS versions if min/max constraints are specified.

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 getConstraints on Safari returns an empty object.
Enable device selection on Safari.

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

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.

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.

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 :-)

* Removes Edge support.

* Removes unused dependency.

* fix(permissions): remove space from requesting camera

Chrome errors on querying permissions with "camera "
because it does not match an expected enum.

* fix(permissions): check value of returned PermissionStatus

A permissions query returns an object with a status/status
of whether or not permission has been granted. Check that
value in addition to the existence of the object.

* fix(permissions): prevent permission being set to undefined

* ref(permissions): move permissions strings to constants

Spot is the consumer of screensharing using a camera
input and through a proxy connection. To differentiate
which one is active, declare a source type on the
created "desktop" stream.

A camera source can be used as a screenshare source.
Normally for screenshare resolution is not capped and
the same will be true for the fake screenshare source.

Actually pass in the option to getTrackSSConstraints so it gets
applied to the desktop track.

This feature is intended for spot. Spot can have an
HDMI -> usb adapter hooked up to it. In that case,
attempting to screenshare should use that adapter
as a screensharing source.

This cleans up the method call, where some duplicate data was passed.

The 'options' identifier is used for different objects, which has lead to a bug where
the object that passes along the 'config.js' provided data is lost along the way. Code
that's further down the execution stack still expects to process that configuration,
which indicates that not passing it along is unintentional.

With this change, an Android device will adhere to the value defined in the 'resolution'
value of config.js, something it currently does not.

Use the W3C Permissions API where possible. At the time of this writing this is
supported in Chrome >= 64.

The code for handling device availability has been disabled for a long time,
plus it's ill named since it represents 2 abstractions: lack of permissions and
lack of devices.

Time for it to rest in the git graveyard.

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

Chrome fires devicechange twice. This causes the DEVICE_LIST_CHANGED
event to fire twice. The listener in jitsi-meet has async logic
to handle the event, including creation of new tracks. So it
can happen that two devicechange events fire, the jitsi-meet
listener fires twice, creates duplicate tracks, and uses both
tracks. Diffing the device list for an actual change is a workaround
against extra devicechange events.

Note: this does not solve the issue in jitsi-meet of it not
handling quick successive DEVICE_LIST_CHANGED events.

Keeps it consistent with the previous implementation.