* fix(stats) Obtain resolution/fps from 'outbound-rtp' stats.
'Track' based stats were dropped in Chrome 112, therefore send resolution and fps for the simulcast case needs to be calculated based on the 'outbound-rtp' streams that are currently active.

* squash: remove an unwanted log

* Squash: Address review comments.
Use outbound-rtp stats for both Firefox and Safari.
Firefox - Ignore active field if not present in the stats and calc fps using 'framesSent'.

Track based stats have been removed recently and RTCRtpReceiver:getSynchronizationSources has been available in the browsers for a while now.

Use the participant ID as the key to codecs, etc, instead of the source
name. The object is further indexed by SSRC.

Don't wait for both codecs to be set before propagating codec
information.

Sample data model for codecs:

codec: {
    participant1: {
        ssrc1: {
            audio: 'opus',
            video: undefined
        },
        ssrc2: {
            audio: undefined,
            video: 'VP8'
        },
        ...
    }
    ,...
}

Some values, like codecs, are available right away, we don't need to
compute differences.

* fix(multi-stream): Fix local SSRC cache to include multiple video streams.
If multiple local video streams are found in the SDP, cache all of them instead of the first video SSRC. This fixes an issue where the resolution/fps stats for the screenshare track are not available.

* squash: new track inherits the source name of old track if it exists.

This allows us to display resolution and framerate stats on separate tiles when multi-stream mode is enabled.

Switch to returning a Promise for getStats. Reset frame rate stat to 0 when video is suspended as a result of endpoint falling out of last-n.

Get rid of the browser specific keys and use the standard spec-compliant fields for stats.
Get the resolution/fps for remote streams from 'inbound-rtp' stats. Use the 'track' stats for the local resolution/fps since these take the active simulcast streams into account.

Capture the audio levels only for the top 5 speakers as RTCRtpReceiver#getSynchronizationSources can be expensive when we have too many audio receivers in the call.
Also, capture the audio levels for track that are unmuted if RTCRtpReceiver#getSynchronizationSources is not supported.
Switch Safari to using getStats since its reporting errorneous values, i.e., 0.000001 as audio level for all remote audio tracks.

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.

The audio levels reported on the audio receivers are lower when compared to the value reported by getStats.
Values reported by getStats on chrome do not follow the the spec and since we have combination of clients using both getStats and getSynchronizationSources,
lets stick to one scale to make them look uniform.
Also, the receivers seem to be reporting audio level for a little bit after the remote user has muted. Make sure the track is unmuted
before setting the audio level on the track.

* 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

This has become obsolete thanks to ES6 arrow functions

This adds the 'codec' object to the RTP stats passed out of lib-jitsi-meet.

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

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.

The 'self.errorCallback' was passed incorrectly - it should have been
bound to 'self' eventually, but now the arrow function is the preferred
way.

There is nothing asynchronous about the initialization process (anymore), thus
turn it into a synchronous method.

In addition, WebRTC support is absolute, it cannot change from not being
supported to being supported (as it plreviously could, thanks to Temasys) so get
rid of the ancillary logic to support that.

Last, introduce a way to check if WebRTC is supported in the current
environment: JitsiMeetJS.isWebRtcSupported().

Enables RTPStatsCollector for react-native. The getStats method was
supported long time ago, but the stats produced by the RTPStatsCollector
were not consumed. Now they are needed for the automated testing on RN.

Adds stats and audio levels for Safari. Enables the new getStats API for Firefox, that will get rid of the following warning:
'non-maplike pc.getStats access is deprecated, and will be removed in the near future! See http://w3c.github.io/webrtc-pc/#getstats-example for usage.'

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

ESLint 4.8.0 discovers a lot of error related to formatting. While I
tried to fix as many of them as possible, a portion of them actually go
against our coding style. In such a case, I've disabled the indent rule
which effectively leaves it as it was before ESLint 4.8.0.

This commit changes the way the average stats are being reported to the
analytics backend. Instead of prefixes for the different scenarios
("p2p_", "jvb121_" and no prefix for multi-party calls) we now have
properties that allow to distinguish which scenario an event pertains
to. The query language of the analytics backend can be used to build
appropriate queries that group by those properties.

Additionally, we now report whether the average stats event concerns a
relayed call (a call that's routed via a TURN server) or not.

* feat: multiple, simultaneous RTP stats

Makes it possible to have remote RTP stats running for more than one
peerconnection at a time.

* feat(stats): report RTT all the time

Will report JVB RTT (and end to end) while in P2P mode and vice versa.

* fix(JitsiConferenceEvents): remove CONNECTION_STATS

CONNECTION_STATS event is no longer emitted.

* fix(AvgRTPStatsReported): users with no video

Do not include FPS == 0 in average remote FPS calculation. Report NaN
for local FPS when video muted or no video device. NaN will be reported
for avg remote FPS if no video is received.

* fix(AvgRTPStatsReported): reset total packet loss

* feat(AvgRTPStatsReported): report 'screen' FPS

Will report average FPS for screen videos separately from camera videos,
but only if available (camera video reports NaN FPS when not available).

* fix(AvgRTPStatsReported): end2endRTT

Needs to report JSON with value.

* feat(AVG RTP stats): separate audio and video bitrate

Will report average audio and video bitrates separately.

* doc(JitsiConference): try to improve comment

* fix(AvgRTPStatsReporter): remove confusing reset

There's no a clear reason for doing reset there.

* ref(AvgRTPStatsReporter): rename var

* ref: store SSRCs as a number

Converts all the places where SSRCs where stored as string to use
numbers.

* doc(RTPStatsCollector): getNonNegativeStat

Fixes invalid description about returning NaN.

* ref(JitsiConf...EventManager): simplify for..of

* ref(JitsiRemoteTrack): throw TypeError

Will throw a TypeError when 'ssrc' is not a number.

* fix(RTPStatsCollector): invalid reference

* doc(RTPStatsCollector): getNonNegativeStat private

* ref(RTPStatsCollector): simplify for..of

* fix(SSRCs): check for negative value

Will not accept negative SSRCs, since those are supposed to be unsigned.