fix(live): only reset playlist loader for LLHLS

Description

After a LOT of debugging with playlist changes against a linear DASH stream, I discovered we're calling resetLoader when setting a new playlist (during a rendition switch), which sets fetchAtBuffer_ to false then calls resyncLoader. This sets the mediaIndex to null, which eventually on the next chooseNextRequest_ call (which as implied, chooses the next segment to request) forces us into the else logic. Because fetchAtBuffer_ is false, we begin requesting segments from the currentTime rather than the end of the buffer. This causes the playback watcher to assume a segment download has stalled, because when we request segments at the currentTime we're either requesting cached segments or overwriting segments that were already buffered, which results in the buffer not changing and an increment of the stalled segment counter.

Specific Changes proposed

Since this logic was originally implemented as an fix for LLHLS playback (see: https://github.com/videojs/http-streaming/pull/1201) we can isolate it to LLHLS streams by checking for a partTargetDuration on the playlist, which is required for LLHLS streams, see: https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-4.4.3.7. This greatly reduces the re-requesting of already buffered and cached segment requests during live playback and in turn the stability of these streams as the buffer isn't being artificially starved during a rendition switch.

Requirements Checklist

[x] Feature implemented / Bug fixed
[x] If necessary, more likely in a feature request than a bug fix
- [x] Unit Tests updated or fixed
- [ ] Docs/guides updated
- [ ] Example created (starter template on JSBin)
[ ] Reviewed by Two Core Contributors

videojs / http-streaming