feat(twa) add TWA check function

* ref: Do not include the full JSON when firing event (unused).

* ref: Logging and formatting fixes.

* added setLocalParticipantProperty doc
* PARTICIPANT_PROPERTY_CHANGED event doc added

* fix(docs): refactor and fix formatting
* fix(docs): add missing options
* fix(docs): change confusing link naming in README

Closes #1272

Also return early to avoid weird errors if the initialization step fails.
Everything is broken at that stage pretty much.

seen in #1364 but it is older

In Chrome, if 'maxBitratesVideo' options are specified
and 'capScreenshareBitrate' is disabled, then simulcast is enabled
for screenshare. Chrome in plan B, does not send screen stream if
'maxBitrate' are set and simulcast is enabled.

and add a few new ones.

and make them a bit more concise. No functional changes

Always attempt to discover the configured STUN/TURN servers.

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.

When using getSynchornizationSources on the audio receiver to gather audio levels for remote tracks, browser reports last known audio levels even when the remote user is audio muted, we need to reset the value to zero here so that the audio levels are cleared.

On Safari, MediaStream.onremovetrack is not fired when a remote desciption with a removed MSID is applied. As a result, new remote tracks for the same endpoint are not created causing issues where the video is not updated on Safari. Also, make sure local tracks on pc are updated when devices are changed while the user is in muted state.

this uses the full four bits in the wire format. The wire format
looses the (currently not implemented) extensibility with variable
length keys.

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

Both for just encode function as well as an end-to-end test.

Disable RTX on FF as we are seeing video freezes on FF80 and later - https://bugzilla.mozilla.org/show_bug.cgi?id=1668028

to allow writing tests

in particular this allows sharing the ratcheting between the E2EEncryption
module and the Worker.

similar to what is explained here:
  https://tools.ietf.org/html/draft-omara-sframe-00#section-4.3.5.1
but we do it on authentication tag failures since it is not possible
to tell whether decrypt.

this needs to be called with an Uint8Array, not an ArrayBuffer

Adds a JitsiConference.getSsrcByTrack() method that finds the SSRC of a JitsiTrack by its SSRC. This method is currently used to get (and display) the first audio/video SSRC in the GSM popover in Jitsi Meet.

Co-authored-by: George Politis <gp@jitsi.org>

* add p2p meta info to pc

* fix typos

refactor the signature checking to make it clear when we need to ratchet.
This is similar to
  https://tools.ietf.org/html/draft-omara-sframe-00#section-4.3.5.1
but we verify the hash before attempting to decrypt.

following
  https://tools.ietf.org/html/draft-omara-sframe-00
but putting the frame metadata into a trailer instead of a header.
We call this JFrame.

Also the key we get from OLM is high entropy so we do not need
to use PBKDF2 but can use HKDF instead. See
  https://wiki.developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/deriveKey#HKDF

Since we use transferable streams to transfer the streams to the worker
we need to feature detect them as Chrome 86 will launch Insertable Streams
by default without shipping transferable streams yet (status still unclear,
it might still ship too)

See here for the feature detection used:
  https://groups.google.com/a/chromium.org/g/blink-dev/c/1LStSgBt6AM/m/hj0odB8pCAAJ

This should fix the case when camera is started with 1080p and LD simulcast stream's resolution is 270p but the requested resolution is 180p.

This the second stage in our E2EE journey.

Instead of using a single pre-shared passphrase for deriving the key used for
E2EE, we now establish a secure E2EE communication channel amongst peers.

This channel is implemented using libolm, using XMPP groupchat or JVB channels
as the transport.

Once the secure E2EE channel has been established each participant will generate
a random 32 byte key and exchange it over this channel.

Keys are rotated (well, just re-created at the moment) when a participant joins
or leaves.