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.

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.

Add a performance stat around long tasks. Chrome supports PerformanceObserver API that lets us
register for long tasks event. Any task that takes longer than 50ms is considered a long task.

A new method which not only has Promise interface,
but also allows to queue IQs regardless of the current
connection's status.

Ping and send ICE failed notification requests are changed
to use this method which makes it more reliable on XMPP
Websocket connections on mobile(which in contrary to BOSH
dies much faster there).

It makes it easier to remove listeners.

* feat: implement vad noise detection

* start detection services on initial track add

* additional refactor / calibrate noise detection

* stop detection services on track remove

* address code review

* address code review p2

Also do not execute any peerconnection callbacks like
'oniceconnectionstatechange', 'onicecandidate' etc. after close.

* revert: Reverts be665cbff7.

* ref: Renames "peerjid".

* ref: Refactors the initialization of a peer connection.

* feat: Re-implements the A/B test for the "suspend video" feature.

* squash: Deep copy.

* ref: Renames forceSuspendVideo to abtestSuspendVideo.

Our JSHint configuration is not extensive and we have excluded multiple
files from linting. Additionally, we have seen JSHint to be unable to
parse newer ECMAScript features such as the object spread operator
(proposal).

On the other hand, we have seen ESLint to beautifully work on React and
React Native source code in addition to ES2015 and later. Introduce
ESLint alongside JSHint as an intermediate step to eventually switching
from JSHint to ESLint.

As our source code does not fully follow even the JSHint rules we have,
it is very difficult to introduce ESLint with many rules. At the
beginning, introduce it with as little rules as possible. Morever,
ESLint is able to automatically fix certain rule offenders so once we
have ESLint merged we can incrementally add new rules while keeping our
commits' modification on as little subjects as possible.