fix: Use only packet loss for the send direction.

This is only temporary, since we suspect that the calculation for the
receive direction is incorrect.

Conn quality

Second attempt on #292

Fix Uncaught TypeError: Cannot read property 'getTracks' of undefined

If there was no notification from the JVB about the connectivity status
it means it's connected. That's because the bridge does not send any
notification unless there is a problem.

The manager will not forward the event if the participant does not
exist, as it is not expected to get the event for "undefined"
participant.

Initialize lock state on room join.

Cleans up code. Paces the increase of connection quality. Take ramp-up
into account. Uses sending bitrate by default whenever possible (with
and without simulcast, as long as we know the sending bitrate and
resolution).

Updates the packet loss based calculation (used whenever we don't know
the sending bitrate and input resolution) with hard-coded thresholds,
so that it doesn't scale linearly (15% packet loss doesn't yield 85%
connection quality).

feat(JitsiLocalTrack): Add the result from isReceivingData method to callstats loging

Remove audio problem detection

LocalStatsCollector uses a global AudioContext for implementing metrics on webrtc audio streams. If there is an audio stream the stream gets attached to the global AudioContext and metrics for this stream are collected.
When using lib-jitsi-meet with no audio streams (for example only screen sharing) the orphan AudioContext does have a default audio level. In other words even if no audio stream is attached to it the element plays some default sound using cpu/battery and most crucial in clients with virtualized harware causing network traffic to send audio output to local hardware which clients are operating.
The solution provided suspends the global AudioContext right after its creation. Therefore, there is no default audio signal emitted by it.

Page reloads on BOSH HTTP errors

If Strophe drops the connection while not being asked to, it means that
most likely some serious error has occurred. One currently known case is
when a BOSH request fails for more than 4 times then the connection is
dropped without supplying a reason through the Strophe API
(the connection status simply goes to DISCONNECTED).

Fix participant connection status stuck after device switch

fix(ChatRoom): Cannot read property 'roomjid' of undefined

fix(statistics): sendEventToAll was not passing string to callstats

Jingle and SSRC updates

When the remote track which caused to transit to the disconnected status
is removed from the conference the current status received through
the data channels should be used to avoid getting out of sync by missing
"muted"/"unmuted" events sequence.

Usually the track removed is replaced by the new one(in our use cases),
but the new track is always added unmuted. Now if the connection gets
restored in the meantime while the track is being signalled then
the 'muted/unmuted' event sequence may be missed and the participant
might be blocked in the "disconnected" state forever.