fix: Fix errors with TS segments on Chromecast

[JulianDomingo]

On Chromecast devices, TS-based streams tend to be more susceptible to failures related to the Cast platform's MSE implementation.

One of these failures was observed when Shaka Player updates SourceBuffer#timestampOffset within MediaSourceEngine#appendBuffer():

1. To extract a timestamp from MediaSource to align text segments:

   shaka-player/lib/media/media_source_engine.js

   Line 657 in 3d0f752

   sourceBuffer.timestampOffset = originalOffset;

2. To re-align segments as a result of an unbuffered seek or automatic adaptation:

   shaka-player/lib/media/media_source_engine.js

   Lines 684 to 686 in 3d0f752

   	this.enqueueOperation_(
   	contentType,
   	() => this.setTimestampOffset_(contentType, timestampOffset));

The Cast platform throws the following error:

...
"stack":"Error: Failed to set the 'timestampOffset' property on 'SourceBuffer': The timestamp offset
may not be set while the SourceBuffer's append state is 'PARSING_MEDIA_SEGMENT'.
...

One way of resolving this is to reset the SourceBuffer's parser state, which in turn resets the append state from PARSING_MEDIA_SEGMENT => WAITING_FOR_SEGMENT: https://www.w3.org/TR/media-source-2/#sourcebuffer-reset-parser-state.

On Cast devices, the issue is reproduced consistently when Shaka switches to a new variant. There are no internally queued MSE operations in MediaSourceEngine when the error is thrown. Based on these observations, the input buffer passed to MediaSourceEngine seems to be an "incomplete" media segment, meaning the SourceBuffer#appendBuffer() call exits when the append state is still PARSING_MEDIA_SEGMENT (Step 6.4 in W3C specs) hence the error.

This is also suggested as a root cause from a Chromium engineer, with one suggested solution to call abort() beforehand (source). Since Shaka Player already does preemptive abort() calls when setting stream properties, this will do the same thing.

[joeyparrish]

Since this does both a delay and an updateend() event, maybe call it simulateUpdate() or something? Reading the test body without the definition of delay(), you might expect it to only wait for time to pass.

[JulianDomingo]

That's true, updated!

[github-actions]

Incremental code coverage: 100.00%

[joeyparrish]

LGTM without the Cast-specific regression test. If we can get that in, great. If not, this is still an important fix that we should get out to partners.

[joeyparrish]

The new test case fails on Chromecast without the fix, and passes with it. Nicely done!