This bug tracks the work necessary for the next libwebrtc update (2H 2020).

Information needed to perform this update is documented at https://wiki.mozilla.org/Media/WebRTC/libwebrtc_Update_2H2020 .

The process is documented at https://wiki.mozilla.org/Media/WebRTC/libwebrtc_Update_Process .

This code comes from the rollup of previous local patches to upstream, see
https://hg.mozilla.org/mozilla-central/rev/c8e80efab6fb

This is needed to not regress stats. The milliseconds unit is more prevalent in
upstream stats code for timestamps.

This is similar to how it's already included for video send.

This switches those integrations to the new Call API, with AudioSendStream and
AudioReceiveStream as main API surface.

This will be used in PeerConnectionImpl for packetsReceived on the send side (from
rtcp).

For AudioConduit this patch:

• Uses correct threads per upstream, pending changes due to the threading model
  update that's coming
• Uses new upstream APIs for getting data for the stats

For VideoConduit this patch:

• Removes the stats polling 1-second timer on main thread
• Removes the internal stats classes for bridging stats between main and sts
  threads
• Uses correct threads for direct access per upstream's thread checkers, pending
  changes due to the threading model

For PeerConnectionImpl and RTCRtpReceiver this patch:

• Manages thread access into conduits for thread safety
• Translates from the upstream Stats data models into our DOM data model

These fixes are made to reflect the current state of upstream.

This sets up our code for creating Call instances so that it works. A number of
things are left to do. Most notable fixing the threading model.

Until that is fixed we use main thread as a "worker" but this is not ideal.
It both leads to excessive work loads on main, and us having to set main as
"current" (using upstream's API for this) whenever we call into main from what
is meant to be the worker thread.

Doing this outside of the dtor, especially, removes the requirement of the
conduit having to be destroyed on the worker thread (main).

Not having threading requirements on the conduits' dtor means we can constify
conduit members everywhere, so this patch tries to do that, for added compiler
guarantees.

This assert was intended for when an input stream is started with processing on.
However, when an input stream is started with processing off, then later when
processing is turned on it triggers this assert because mSegment contains data
from InsertInGraph().

Depends on D102289

The new AudioProcessingImpl, and in particular AEC3 it seems, is more picky on
the ordering here. After an ApplyConfig() it needs ProcessStream() to properly
set up its internals. ProcessReverseStream sets off various asserts, for
instance because the processing sample rate is not divisible by 16k if
ProcessReverseStream() was fed 44.1k.

The input stream is not processed in passthrough, so we should skip feeding the
reverse stream too, to stay in sync.

This should also work with libwebrtc 64 currently in-tree.

This removes some prefs for things that are now unconfigurable, and adds some
others. This also re-works the plumbing for updating the config on the fly
through applyConstraints(). It is now simpler, with a single infallible call
to apply the new config.

Before this patch, if the data callback contained less data than was left over
from the last iteration, we'd skip iterating the graph again. The graph is
however is capable of 0-iterations.

This patch removes that optimization so that every data callback results in an
iteration.

This makes it easier to defer processing input data to the track processing
step, as is needed by the next patch in this stack, to keep input and output as
handed to AudioProcessing in sync as config changes are applied with
ControlMessages (in between input and output data notifications). With input
data processing deferred, ControlMessages are run first, then processing of
input data and last processing of output data.

These previously allowed a discontinuity at the beginning of the output stream.
This will no longer occur.

This is similar to the behavior prior to bug 1532898, which introduced telemetry
reporting every second. There's a bit of a difference in that we only report
data if we had collected some though the 1 second interval telemetry timer in
PeerConnectionCtx.

This patch uses mMutex to guarantee that the audio thread does not get things
pulled away from under its feet. When on the AudioProxyThread we allow blocking
the thread during negotiation. On the real audio thread we avoid blocking on
the mutex and return an error instead. This leads to us inserting silence --
which is fine since we're going through negotiation (call setup, teardown or
re-negotiation).

This also fixes the channel count when GetAudioFrame fails and we insert
silence, to use the same channel count as when we last appended real data. Since
changing the channel count can in the worst case cause a GraphDriver switch.

Prior to this patch, WebRtcCallWrapper would never clear the call instance,
meaning that it went away as the classes having references to WebRtcCallWrapper
also went away. These are mainly TransceiverImpl and PeerConnectionMedia. There
are other classes too, but these are the ones that have a strong-ref to
WebRtcCallWrapper and are cycle collected.

With the worker threads in libwebrtc now using our own TaskQueues on top of
our SharedThreadPool instances, the ownership model of the Call instances
becomes problematic.

On shutdown, xpcom-shutdown-threads happens before the cycle collector is shut
down.

xpcom-shutdown-threads will however, block shutdown until all SharedThreadPools
have been shut down.

If a TransceiverImpl sits around until shutdown it will only be destroyed
during cycle collector shutdown. And, alas, we reach a deadlock as we're stuck
in xpcom-shutdown-threads until that TransceiverImpl gets destroyed.

This patch decouples the Call instance lifetime from the cycle collector, and
avoids the shutdown hang.