Because of WebRTC's blocking-invoke threading model, the order of events
are not always the same in the content and webrtc layers, causing bugs
in some edge-cases.

For example, addTrack() and setLocalDescription() both modify the set
of transceivers. addTrack() does so with a blocking-invoke, and SLD()
does so asynchronously, where the state change is surfaced in a
callback.

In rare cases, it is possible for addTrack() to modify the sender's
track and then for a setLocalDescription() callback carrying outdated
transceiver state information to null the track. And similarly this
could happen reverting changes to the transceiver's direction.

This makes the content layer not reflect the webrtc layer, which in
the referenced bug even causes a crash because a track adapter no
longer exists.

The fix is not to update "transceiver.sender.track" or
"transceiver.direction" in SLD/SRD callbacks for transceivers that
already exists. This is valid, because these fields can only be
modified by other APIs (addTrack, replaceTrack, direction, etc) and
not by SDP.

Bug: 950280
Change-Id: Icdcc65c5f8b5861550bda588597b88f6103c4f70
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1566346
Commit-Queue: Henrik Boström <hbos@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#651234}