jitsi-meet-spot currently supports mobile browsers. A
line should be drawn somewhere but maybe not here.
Chrome iOS does not have navigator.mediaDevices so add
a truthy check before checking for getDisplayMedia.

Spot is the consumer of screensharing using a camera
input and through a proxy connection. To differentiate
which one is active, declare a source type on the
created "desktop" stream.

A camera source can be used as a screenshare source.
Normally for screenshare resolution is not capped and
the same will be true for the fake screenshare source.

Adds a flag which can be used to disable talking to Jicofo. It's
intended to be used only in jitsi-meet-spot which joins a special room.

Actually pass in the option to getTrackSSConstraints so it gets
applied to the desktop track.

Supported since Firefox 66.

Because it's possible to go back from ICE FAILED state to CONNECTED it's
better to give it some time until the XMPP connection recovers and only
if they ICE does not recover in time send the ICE failed notification
to Jicofo. It's done by sending a ping to the XMPP server and checking
the ICE after 2 seconds past the ping successful response.

Make the client send ICE failed notification to let Jicofo know
that the ICE connection with the bridge has failed. It can then
re-create the channels and send new transport in the
'transport-replace' message to give it another try.

Also adds a bridge session ID so that Jicofo can discard outdated
requests. When a bridge dies multiple clients may send ICE failed
notifications at the same time. Jicofo will detect bridge failure
when processing the first one and it must not act on the following
requests for the broken bridge session which is no longer current.

A bridge session ID will be sent in new 'bridge-session' XML element
which is part of either 'session-initiate' or 'transport-replace'
message. The server's region is moved to this element as well as
it's part of a bridge session.

It should be provided by the environment, just like on web. This avoids bundling
callstats on web, where it won't be used (we dynamically download it).

This reduces the bundle size from about 1MB to 675KB, almost 40%.

* feat(screenshare): support remote wireless screenshare

- ProxyConnectionService is exposed and meant to be the
  facade for creating and updating a peer connection with
  another peer, outside of the muc.
- ProxyConnectionPC wraps JingleSessionPC so the peer
  connection handling can be reused.

* attempt to make more configurable

* Fix: Old JitsiConference instance remains listening on incoming calls after leave - rejoin to same room

* Remove all listeners added by setupXMPPListeners

This feature is intended for spot. Spot can have an
HDMI -> usb adapter hooked up to it. In that case,
attempting to screenshare should use that adapter
as a screensharing source.

Reset the state of remote MediaStreams in order to fix sequence number
synchronization problem. When a conference is moved to another bridge or
if channels are re-allocated the bridge looses the most recent sequence
number seen by the client which makes Chrome drop all video packets
until the JVB catches up with the sequence numbers (if at all).

Changes the behavior to actively open new WebRTC Data Channel instead
of waiting for the JVB to do it.

Adds ICE_RESTART_SUCCESS event used to re-initialize the data channel in
case of ICE restart where the conference could have been moved to
another bridge.

feat(ScreenObtainer): fix support for old getDisplayMedia

Chrome 71 does not support inline installs, but has navigator.getDisplayMedia
behind a flag. Support this case.

Fixes tests.

Updates speakers stats with values received by the spealerstats component, all the logic is activate only in case we discover speakerstats component address from disco-info and the incoming message is coming from that component.

When the main domain advertises component with type 'speakerstats' every participant will send message to the component with the name of the room where this happen.

build: fix setting webpack mode

Starting in Chrome 71, tracks without a stream are
given the msid "-", which in plan b incorrectly
triggers an onaddstream even with a default local
stream.

fix(docs): update url for loading lib

deps: update to webpack 4

fix(RTC): Pass options allowing GUM to work with config

This cleans up the method call, where some duplicate data was passed.

The 'options' identifier is used for different objects, which has lead to a bug where
the object that passes along the 'config.js' provided data is lost along the way. Code
that's further down the execution stack still expects to process that configuration,
which indicates that not passing it along is unintentional.

With this change, an Android device will adhere to the value defined in the 'resolution'
value of config.js, something it currently does not.

It's supported in Chrome >= 65.

* ignore duplicate jibri status updates

* re-add mistakenly removed return

fix(RTPStatsCollector): this.stop is 'undefined'

Until M69 Chrome used to consistently emit "onstreamadded" when
audio/video stream is added for the first time and then emit track
events only if the stream is modified afterwards (video track replaced).

However it looks like now it can first emit "onstreamadded" and then
additional "ontrackadded" for the MediaStreamTrack that was already
included in the MediaStream signalled by the "onstremadded" event. I
have not managed to figure out what is causing this and the only
difference in the SDP is the fact that the remote peer (JVB) includes
IPv6 candidates. Anyway it doesn't hurt to have such a safeguard.

The 'self.errorCallback' was passed incorrectly - it should have been
bound to 'self' eventually, but now the arrow function is the preferred
way.