Could not update karma-webpack to latest as it was not running because of an error:
The "path" argument must be of type string. Received type object
https://github.com/webpack-contrib/karma-webpack/issues/350

Chrome fires devicechange twice. This causes the DEVICE_LIST_CHANGED
event to fire twice. The listener in jitsi-meet has async logic
to handle the event, including creation of new tracks. So it
can happen that two devicechange events fire, the jitsi-meet
listener fires twice, creates duplicate tracks, and uses both
tracks. Diffing the device list for an actual change is a workaround
against extra devicechange events.

Note: this does not solve the issue in jitsi-meet of it not
handling quick successive DEVICE_LIST_CHANGED events.

This simple change helps to prevent `'The conference is has been already left'` error after kick. 
`Conference.leave` will detach chatRoom instance itself.

Keeps it consistent with the previous implementation.

When using the Promises API, modern constraints are used, so adapt to it and use
the modern versions.

Just use navigator.mediaDevices.enumerateDevices().

It's 2018 after all...

Get rid of all wrappers and use navigator.mediaDevices.getUserMedia, since all
supported platforms have it by now.

Also use the unprefixed versions of WebRTC APIs.

Emit ACTION_JINGLE_SI_TIMEOUT analytics event if it takes too long for
Jicofo to send session-initiate (it usually arrives within 1 second).

JingleSessionPC cleanup

The previous check looks like it was meant to check if it's
the initiator.

The options are coming from the config anyway.

* feat: Adds the user's region to presence. Fixes typos.

* feat: Measures end-to-end RTT with ping over the data channel.

* feat: Adds a couple of permanent analytics properties.

feat(RTC): refactor logic for polling for device changes

- Don't use it on supported browsers
- Make sure no stray timers are left

fix(audio-output): return the reject promise

* Enables adapter for edge.

We were not filtering correctly all unsupported iceServers and an error is thrown and no connection is established.

* Enable desktop sharing for Edge.

Currently when replacing video track with desktop sharing one, doesn't work because of: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/17528460/
If Edge user joins first and enables desktop sharing it will work when others join. Tried also to use replaceTrack/setTrack as a workaround, but again we hit an error, this time InvalidAccessError.

* Adds the helper function usesAdapter in BrowserCaps.

* feat(conference): expose method to select multiple participants

* squash: fix typo

* squash: reduce to one code flow

* squash: default to empty array to mimic previous null default

* squash: fix typos, change docs, default params

* squash: remove defaults

* squash: update comment about array arg

* ref(video-quality): cache max frame height and send on channel open

Currently it is possible to try to change the max receive video
frame height before the data channel is open. In that case an error
will be thrown. This change makes it so that the desired frame height
is saved and sent on channel open, avoiding the thrown error the
max receive video frame height logic is exercised through the
JitsiConference api.

* squash: do the second part of the actual fix

* Change layer suspension to use parameters in RTPSender

We no longer suspend unused simulcast layers via a bandwidth cap in the
SDP, instead we'll use the new parameters in RTPSender to enable and
disable streams explicitly.  The main advantage here is the RTPSender
method ramps up immediately when we re-enable the layers (as opposed to
the SDP bandwidth cap which took 30+ seconds).

* Fix linter issues

* Uses json message extension

* Sends json-message without the body element

* Info comments and parameter order changes

1. The example was using the Promise return value of JitsiMeetJS.init
which is no longer possible/correct after commit "core: refactor
initialization not to return a Promise".

2. We went back and forth with the value returned by JitsiMeetJS.init:
we initially didn't return a value, then we started returning a Promise,
and now we're not returning a value. Whether we'll go back to returning
a value is up in the air. Anyway, the return value is practically
determined by the last in a chain of function calls: JitsiMeetJS, RTC,
RTCUtil. Since the chain is not really documented, it will not hurt much
to make it easier to refactor the chain by "composing" the functions.

There is nothing asynchronous about the initialization process (anymore), thus
turn it into a synchronous method.

In addition, WebRTC support is absolute, it cannot change from not being
supported to being supported (as it plreviously could, thanks to Temasys) so get
rid of the ancillary logic to support that.

Last, introduce a way to check if WebRTC is supported in the current
environment: JitsiMeetJS.isWebRtcSupported().

RTCUtils.attachMediaStream was changed not to return elements;
instead it returns undefined by default. When mapping over
containers and call RTCUtils.attachMediaStream, containers
would be changed to undefined.

The case where we had created recvonly streams (start muted on FF) and we are unmuting, this creates a sendrecv stream and adds msid, we need to signal msid so listeners to be notified and create appropriate audio/video element and to start receiving the stream.

User may decide to abort the connection while it's stuck at connecting.