Fix infinite buffering when locking audio/video on *TrackChange or periodChange events

[peaBerberian]

An application signaled to us that there was infinite rebuffering happening when calling the lockVideoRepresentation API directly in a videoTrackChange or periodChange event listener.

It's actually a sort of reentrancy issue:

1. The periodChange AND videoTrackChange events are sent as soon as all initial video+audio+text Representations are kown for the current Period.

   The RxPlayer knows when it is the case when its AdaptationStream modules call their representationChange callback (a sort of event emitter system) for each type of buffer (video, audio and text).

   All this happens synchronously: as soon as the last of the 3 representationChange callback is called, we're emitting both videoTrackChange and periodChange events.

2. The application calls the lockVideoRepresentations API synchronously after step 1 by listening to the aforementioned events

3. That lockVideoRepresentations call leads to a different choice of Representations, so the AdaptationStream re-call the function that calls the representationChange callback (note that neither periodChange nor videoTrackChange are re-sent here, we know that we already sent both).

4. As everything was called synchronously here, we continue the execution of the corresponding AdaptationStream's function called in step 3 but also, once this is done, the execution of that same function in step 1 (with the previous Representation's context).

5. So technically, the application and the RxPlayer want the Representation set in step 3, but for the AdaptationStream, it most recently did work to have the one wanted in step 1.

   What's worse is that some parts of the RxPlayer knew it was the one in step 3 that was wanted, yet other parts wanted to load the one in step 1, leading to nothing being done in the end (video segment requests were cancelled and not restarting).

We know very well this type of issues because a media player is heavy on events handlers we do not control (i.e. in which the application may do what it wants), but it turns out that we relied on the wrong "CancellationSignal" here.

The CancellationSignal is the main way with which we protect the code against this type of issue by "activating" one when we want to cancel the execution of some logic (here the one from step 1).

Here we were, after the representationChange call from step 1, checking the CancellationSignal which is linked to the whole AdaptationStream module. As the AdaptationStream is not interrupted by a change of Representation, that signal was not activated here.

What we probably wanted instead was to rely on fnCancelSignal, which is the one linked to the scope of that function.

[Florent-Bouisset]

nice catch 👍

[peaBerberian]

I think integration tests will be easy for that one (just call lockVideoRepresentations on a videoTrackChange and periodChange events and see if it plays) so I'm keeping it open until I wrote them