feat: Add config to allow reset MSE on cross boundary

[matvp91]

There's devices out there that are not compliant with the MSE spec. Such as halting MSE when a secondary init segment is appended (webOS 3), or failing to transition from a plain to encrypted init segment (Tizen 2017). While we initially prefer content workarounds, it's a time consuming and trial & error process. For some devices it might not be worth investing time into finding a proper workaround due to low usage. We're giving people an alternative by resetting MSE when needed (configurable). dash.js offers somewhat similar behavior here, where MSE is reset before applying an encrypted init segment.

This PR introduces crossBoundaryStrategy in StreamingConfiguration. It can be configured as following:

• KEEP - we're keeping MSE active, this is the default and the current behavior.
• RESET - we'll always reset MSE when it crosses a boundary.
• RESET_TO_ENCRYPTED - we reset MSE when it crosses an encrypted boundary, and we keep MSE afterwards. Additionally, we're not going to reset when we're crossing a plain to plain boundary.

Each initSegmentReference now holds an encrypted and boundaryEnd value. When configured with a different value than KEEP, StreamingEngine will be instructed to fetch and append segment references up until the boundary of the currently applied init segment.

We detect whether we're at a boundary in a few ways:

• Listening to the HTML5 MediaElement's waiting event, this'll indicate that we do not have enough buffer to advance. If we're pretty close to the boundary, we assume we're at the boundary.
• Due to subtle differences in the segment alignments, waiting wasn't reliable. When close to a boundary, a timer is fired with the assumption that "we'll reach the boundary at soon". I've set the threshold to 1 second, when playhead is further than the threshold, we'll skip checking whether an MSE reset is due.

The implementation relies on the added properties in the init segment reference, and the concept of a "Period" is avoided in StreamingEngine to ensure it's compatible with HLS too.

[shaka-bot]

Incremental code coverage: 96.02%

[avelad]

@shaka-bot test

[shaka-bot]

@avelad: Lab tests started with arguments:

• pr=8156

[avelad]

@shaka-bot test

[shaka-bot]

@avelad: Lab tests started with arguments:

• pr=8156

[avelad]

@shaka-bot test

[shaka-bot]

@avelad: Lab tests started with arguments:

• pr=8156