s/updateCurrentKey/updateCurrentMediaKey/g

It implements SAS verification as per the Matrix spec, adapted to our environment.

the editor will no longer complain about superfluous await when calling

it removed support for functions being simultaneous async and have done parameter in callback

the editor will no longer complain about superfluous await when calling these functions

For some reason webpack seems to not be transpiling that properly.

Fixes: https://github.com/jitsi/lib-jitsi-meet/issues/1722

An alternative to Insertable Streams, currently implemented in Safarii / WebKit.

https://w3c.github.io/webrtc-encoded-transform/

Fixes: https://github.com/jitsi/jitsi-meet/issues/9585

remove legacy APIs which are not even supported anymore

Get rid of noisy logs related to SDP transformations which are redundant. Fix formatting and add missing information.

Drop end to end signature. The impersonation attack vector is deemed out of
scope since insiders are already part of the meeting.

When E2EE is disabled we need just set the last key to `false`. When decoding we
need to check if the last key is not false, otherwise we might try to decrypt
the unencrypted video frames, thus resulting in breakage.

- After ratchet do not set it as new key for current index. Set it to correct position in crypto ring.

Signs and verifies frames. For now this is done on every frame.
This is not the long-term goal and there needs to be a better strategy.

and add a few new ones.

and make them a bit more concise. No functional changes

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

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

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

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

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.

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