[Proposal] Add PlaybackRate-based rebuffering avoidance mechanism

[peaBerberian]

While admittedly checking what other media players were doing that we don't do yet, I saw an interesting opportunity.

Some players have a mechanism where they lower very slightly the playback rate (the speed at which we play) - for example at 0.95 (meaning we play 0.95 seconds of content every second) - if the current buffer size is low, until it gains back an acceptable size again.

I'm not sure of the actual impact this mechanism has in terms of rebuffering avoidance but it seems that it can help.

Because it has potential but has high uncertainties, I propose adding this mechanism as an experimental loadVideo option for now, meaning that we reserve the right to update this API or even remove it at any time. I re-use the experimentalOptions concept I already proposed in several of the currently-open PRs for this.

Because we might want to check the buffer size often when it's close to
the potentially-very-low value where this mechanism activates, I reduced our PlaybackObserver's regular interval from 1s to 500ms. This is the same interval we already tested on low-latency contents so it shouldn't be an issue.

I also for now only enable this mechanism if the application plays at x1, not if it is already updating the playbackRate as I found the wanted behavior in thoses cases harder to define.

Some players also only enable this mechanism on VoD contents, not on live contents. I think that this is a mistake as there's no reason timeshifted live shouldn't be treated the same.

I didn't do the API documentation yet nor link it to the demo because I'm somewhat unhappy for that mechanism's name, for now called playbackRateBasedRebufferingAvoidance.
Even if it describes well what it does, I found that name too long even in the code. I think we may prefer finding it a nicer-sounding name to make the code more readable and the API more approachable, like we did for our "fast-switching concept" (which sadly has now a new meaning for DASH low-latency contents different than ours or dash.js's usage, but that's always a risk and I'm willing to take it).

[github-actions]

✅ Automated performance checks have passed on commit 62060f5f94680f9a1f9b0c97951598af3d4dd53b with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	25.14ms -> 26.17ms (-1.032ms, z: 1.30753)	35.70ms -> 35.55ms
seeking	385.44ms -> 188.76ms (196.681ms, z: 7.66482)	16.80ms -> 760.80ms
audio-track-reload	32.02ms -> 32.03ms (-0.015ms, z: 0.78289)	47.55ms -> 47.70ms
cold loading multithread	51.21ms -> 50.63ms (0.582ms, z: 11.23587)	75.75ms -> 74.55ms
seeking multithread	62.96ms -> 31.88ms (31.084ms, z: 0.56796)	19.80ms -> 20.10ms
audio-track-reload multithread	30.34ms -> 30.33ms (0.010ms, z: 0.44680)	44.55ms -> 44.55ms
hot loading multithread	20.32ms -> 20.05ms (0.271ms, z: 5.07836)	29.70ms -> 29.40ms