Fix Low-Latency part and fragment tracking

[robwalch]

This PR will...

Fix Low-Latency part and fragment tracking issues introduced in v1.3.5 with #5102

• Fix current quality reporting when seeking back from edge in Low-Latency streams #5102
  • Introduced regression: stalling when playing back over segment where some parts were loaded seeking back
  • Introduced regression: unnecessary loading of fragments over parts during Low-Latency playback

Additional enhancements:

• Prevents flushing the forward buffer on smooth switch in live playback when buffer conditions are low
• Fixes loading of live streams with alt-audio using an Hls instance that is already playing an asset with alt-audio
• Return MAP segment (when present) for event frag value in FRAG_PARSING_INIT_SEGMENT events
• Prevents fragment and part requests from being unnecessarily aborted on seeking events
• Fix issues with reuse of player instance when loading additional assets (Playback fails when reloading a manifest #5425)

Why is this Pull Request needed?

Fixes reloading of full segments in Low-Latency HLS streams where some parts of the segment were loaded, but now the part list is no longer available, after seeking back to an earlier time in the playlist. This worked in v1.3.5, but regressed in v1.4.0 with this change to tracking of buffered fragments.

Are there any points in the code the reviewer needs to double check?

The fragment-tracker implementation has been cleaned up to better support part loading. This required the stream-controller to now accept loading of fragments that are being tracked as partially buffered (FragmentState.PARTIAL). This has been the case for the audio stream controller. This was likely not allowed to avoid loop loading on segments that do not start with key-frames or require back-tracking. Some additional testing is needed to verify that this is no longer required.

Resolves issues:

v1.4.0 regression: Reloading of incomplete segments where some parts were loaded is not performed after seeking back.

Checklist

• changes have been done against master branch, and PR does not conflict

[cjpillsbury]

Per out of band convo, I think this is the only place I have some concerns. tl;dr - Maybe I'm missing something, but this only checks the playhead instead of also whether or not there is only a part available for the next candidate buffer part-or-segment. Ideally, we'd apply your in-code rule to prefer segments when:

1. the playhead is "far enough back from the live edge" (this line of code here) AND
2. there is a segment available to fetch for the target time.

This would help avoid potential waiting/buffering if a user is watching an EVENT playlist far behind the live edge and then "seeks to live".

[cjpillsbury]

This would likely result in some degradation of QOE for the case mentioned above, but if we want to get a release out to resolve the regression ASAP, I think that could be done as a followup.

[robwalch]

If there are only parts at more than one target duration from the edge you have an invalid HLS stream.

[robwalch]

The check for only parts would be this.getLoadPosition() > details.fragmentEnd.

[robwalch]

Removed this feature from the PR. Changes are now focused on fixing the regression and edge-cases.

[cjpillsbury]

Pre-approved with one non-blocking callout.