Add synchronization around local track access to JitsiConference

[paweldomas]

Adds an async queue which will execute all operations which
rely on or modify the local tracks state. The operations will
execute in sequential order asynchronously.

Before this change, the following code will yield unexpected results:

const track1 = new JitsiLocalTrack(CAMERA);
const track2 = new JitsiLocalTrack(CAMERA);
const track3 = new JitsiLocalTrack(CAMERA);

conference.addTrack(track1);
conference.replaceTrack(track1, track2);
conference.replaceTrack(track2, track3);

It would have worked if each of the operations would wait for the
previous one to complete:

await conference.addTrack(track1);
await conference.replaceTrack(track1, track2);
await conference.replaceTrack(track2, track3);

However, this adds unnecessary complexity to the consuming applications,
which is especially true if the code that manages the tracks is spread
across different modules (need a central place that tracks promises from
all track operations). Having the queue on the JitsiConference level, rather
than above (jitsi-meet for example), makes the client code simpler.

This problem is not only about making sure that each track operation waits
for the previous one, there's a problem which can not be fixed outside
lib-jitsi-meet. When a new JingleSession is started, it needs to pick up
the local tracks to be used by the session. If it happens that either P2P
or JVB session is processing track operation while another session is
being started, it will use invalid/out of sync local tracks state obtained
from this.rtc.localTracks (see unit test section which covers those
cases). It's possible this could be fixed by adding new code that picks up
the tracks again later, but it's not a universal solution. Having an async
queue to synchronize async operations that modify/access local tracks state
will be useful for new code which needs that in the future.

[jallamsetty1]

As discussed, this is going to be problematic. In both jvb and p2p case, the first track needs to be added to be replaced on the RTCRtpSender associated with the first recvonly transceiver. When a secondary track is added, for jvb, a new transceiver is created and for p2p, a new transceiver is created only when there is no recvonly one. JingleSessionPC::addTracks needs to be modified to take this into account. Right now, it is designed to be used for secondary tracks only and therefore creates a new transceiver for jvb always.

[paweldomas]

By primary and secondary do you mean for each media type, for example:

• primary track will be the 1st video track added to the connection
• secondary track will be the 2nd video track added to the connection?

If there are two tracks, one audio and one video then there is one primary video track and one primary audio track?

[hristoterezov]

@paweldomas Wouldn't all this be handled by the modification queue in JingleSessionPC even before? What will actually cause the unexpected results?

Is the issue that we do bunch of other things outside of the modification queue that we later rely on and they will be out of sync?

[paweldomas]

@hristoterezov the issue is that JitsiConference's track operations(add/replace/remove) as well as the JVB/P2P JingleSession initialization (accept,create offer) rely on this.rtc.localTracks state. You can see that variables get updated only once the operations scheduled on JingleSessionPC resolve. So if you perform either a track operation, or try to initialize new JingleSessionPC, without explicitly waiting for previous track operations to be done, then out of sync state will be taken into consideration.

Note that currently only application that uses lib-jitsi-meet is able to wait for other track operation to resolve, which is the main design flaw. JitsiConference by design can't do it's job correctly. To give an example:

1. JitsiConference starts and a JVB JingleSessionPC is created. It accept the offer and so on. There are no local tracks.
2. User calls addTrack(camera1);, this queues addTracks in JingleSessionPC and this operation is async and takes time. Let's say 200ms.
3. 100ms later, another user joined and started a P2P connection. JitsiConference will not have camera1 in this.rtc.localTracks yet and the P2P session will start without including it in the local tracks of JingleSessionPC.
4. Another 100ms later, JVB JingleSessionPC is done with addTrack and now we end up in a state where JVB JingleSessionPC has camera1, but P2P JingleSessionPC does not.

The idea in this PR for a fix is to use the modification queue to schedule P2P initialization to be executed after the first addTrack. So that it will have camera1 in this.rtc.localTracks when creating/answering the offer. It makes JitsiConference aware of all currently scheduled track operations.

[paweldomas]

I think this is too big of a change to land, let's try to go with this more ad-hoc fix: #2469