If identity validation fails, we should not be leaving JSEP in a state where the description was successfully set.

We cannot really rely on the JSEP engine's rollback here, since that only works for offers. We need a more aggressive rollback here. This is at least partially related to bug 1423365, which we may want to revive.

Ultimately, we may need to allow JsepSessionImpl to be deep-copied, so PeerConnectionImpl can copy it, run the operation on the copy, and if that operation (and all other related operations, which may be in PeerConnection.jsm) succeeds, overwrite mJsepSession with the new copy, and update pointers to JsepTransceivers everywhere it makes sense. Otherwise, we discard the new JSEP session, leaving the original totally unchanged.

If we're going to clone the JSEP engine, first we need to be able to clone SDP

Depends on D150167

The integer index we're replacing here is based on the order in which
transceivers were added. If we clone the JSEP engine for an sRD that happens to
result in the creation of a transceiver, and at the same time JS calls
addTransceiver, we have a situation where the sRD transceiver is added first
to the cloned JSEP engine, but the addTransceiver transceiver is added first
to the old JSEP engine, resulting in them having the same index. So, let's just
use a proper key for this stuff.

Depends on D150168

We could go to the trouble of teaching the JSEP engine to succeed/fail
atomically, but even if we did, we still need to be able to undo a successfully
executed sRD or sLD when identity-related stuff (in JS) fails. The simplest way
to get undo functionality is to clone the JSEP engine, and perform the
operation on one of the copies.

Depends on D150169

This will make it easier to replace the JsepTransceiver a given
RTCRtpTransceiver is using, which is necessary if we're going to be
deep-copying and replacing the JSEP engine.

Depends on D150170

The previous changeset was causing nullptr crashes because RTCRtpTransceiver
was performing an unlink before PeerConnectionImpl got a chance to close. It is
likely that there were already ways to trigger this bug.

Depends on D150171

This fixes a class of bugs where modifications to the RTCRtpTransceivers were
applied before sRD/sLD were completely done (while all of the JSEP and transport
stuff was finished, JS could still be working on identity-related stuff).

Depends on D150172

This fixes the class of bugs where identity-related failures could leave the
JSEP engine in a different state than the JS-observable state, and also the
class of bugs where a failure in the JSEP engine could leave the JSEP engine in
a weird halfway state.

Depends on D150173

https://treeherder.mozilla.org/jobs?repo=try&revision=8c46ecbaeda5495e3e19e6406ff798455cc0a1a4
https://treeherder.mozilla.org/jobs?repo=try&revision=5268df1ea7500f4018ec199854e4d2a0629d8f2b
https://treeherder.mozilla.org/jobs?repo=try&revision=419168634151d2ef053e21c76e50b3ac6c1a2e83

Depends on D150174

Try looks good so far:

https://treeherder.mozilla.org/jobs?repo=try&revision=0c8408990985d91831677b4ea0891142c1d48a99
https://treeherder.mozilla.org/jobs?repo=try&revision=eded99b3f2f0be56f8d1cb9ec9ff77e8f90399eb

I think I'll re-run the gtest suite, just in case.

https://hg.mozilla.org/mozilla-central/rev/7db66c7d7f46
https://hg.mozilla.org/mozilla-central/rev/58439a6601ff
https://hg.mozilla.org/mozilla-central/rev/87692ef0b35d
https://hg.mozilla.org/mozilla-central/rev/732e02234941
https://hg.mozilla.org/mozilla-central/rev/fb9d2e7e5fae
https://hg.mozilla.org/mozilla-central/rev/b046b56d111f
https://hg.mozilla.org/mozilla-central/rev/9c544f877fa4
https://hg.mozilla.org/mozilla-central/rev/d25d7e866391
https://hg.mozilla.org/mozilla-central/rev/52f3bf105790

Copying crash signatures from duplicate bugs.