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

Avoid having to use a code blob.

This error happens in getCurrentlyAvailableMediaDevices

see https://bugs.chromium.org/p/chromium/issues/detail?id=1119653
We'll probably do similar renaming in the future.

We're pretty sure it's no longer necessary with JVB2; and it costs
half an RTT in setup, and stops us being able to choose which
DTLS/SRTP protection profile to use.

* Enable opus/red for the conference even when the browser doesn't support it.

* squash: Remove unused import

The XmppConnection will try to resume the connection
only when the internet is online. This speeds up the process
by avoiding unnecessary connect attempts while offline as each
failed attempt increases the backoff delay.

If ping timeouts two times in a row (25 seconds total)
the XMPP WebSocket connection will be killed and restarted.

..readyState to tell if the connection is connected.

The constraints are applied again after renegotiation is done. This should mitigate a fail case on Safari when the RTCRtpSendParameters are not available until the simulcast streams are added via SDP munging before sLD is called.

 Only add/remove the tracks from the peerconnection so that the camera led turns off on mute.

Configure the encodings on FF after the track is added.

Calculate the bitrate based on the sender video constraint applied on the track and the bitrates specified for different resolutions.

...which contains conference duration in seconds and
performance stats (currently long tasks).

If ICE fails will set the special request restart attribute
in the 'session-terminate' sent to Jicofo in order to restart
the Jingle session.

If there's no capabilities version mapping to user's jid
still allow to discover features (that's the case for Jicofo).

Simplifies the logic for delayed ICE failed event by relying
on XMPP ping instead of the networkInfo module to check
if the internet is online.

There's a plan for using ping to detect XMPP WebSocket
disconnected instead of waiting for timeouts on the network layer.

This also simplifies ICE failed handling logic.

Make 'preferH264' and 'disableH264' as deprecated.

Use 'preferredCodec' and 'disabledCodec' under videoQuality config.js settings for setting codec preferences.
Do not prefer VP9 on Firefox because of https://bugzilla.mozilla.org/show_bug.cgi?id=1633876.

Make sdp munging logic for changing codec preferences more generic
Do not negotiate High profile H264 codecs on when RN clients are in the call

When adjusting transceiver direction only the first one
which corresponds to the local track can be set to 'sendrecv'.

...in setMediaTransferActive. The sender video constraints
are controlling the 'encoding.active' flag and this code
would interfere. It's right now not used anyway as P2P is
disabled in the unified mode. If this modification is
necessary we'll add it back when working on unified P2P
in such a way that will play nicely with the sender constraints code.