[Proposal] add a maxVideoBufferSize constructor option to allow setting a limit for the size of pushed segments

[peaBerberian]

At Canal+, we're playing DASH contents with a big range of video qualities: from some very low quality video to something like UHD HDR qualities with a huge bitrate.

Higher qualities generally fill the device's memory much faster than the lower quality ones. On some devices with low memory (among which mostly smart TVs, chromecasts and set-top boxes), we rapidly can encounter a problem where the player cannot fill the buffer until the set wantedBufferAhead.
Right now, the strategy has been to react to QuotaExceededError possibly thrown by the browser when the buffer is full, by reducing the actual buffer goal when it is emitted (instead of loading 30 seconds ahead as told by the wantedBufferAhead option, we instead will load e.g. only 20 seconds).

Yet this strategy has the following issues:

• this error is only received once the segment that is too big has been loaded. As it will in most cases need to be re-loaded, we could have avoided that first request had we known sooner the limitation
• We do not always encounter this error. Sometimes the browser just silently garbage collect the end of the segment the player just pushed. In that scenario an infinite loop of loading and GC will occur
• The application might not want that the player takes for itself all available memory.

---

Due to all those considerations, we've recently thought about allowing a way to have an adaptive wantedBufferAhead.
It would be at the normal target for non-problematic low quality (keeping it high here is even more important considering that people on low-bandwidth usually have higher risks of rebuffering) but much lower when on high qualities to avoid filling the memory.

But we cannot just rely on the current loaded quality (in which case, the application could do it by itself on player events) as already-buffered segments also may have an impact.

The solution we're currently experimenting is to let the application set a maxVideoBufferSize option (as a constructor option and/or through RxPlayer methods).
The value of that option would be equal to the maximum size of data, in KB, that should be at any time in the browser video SourceBuffer.

As no browser API exist to announce the current size in that buffer, the RxPlayer estimates it by using its internal SegmentInventory, which is a structure keeping information about all segments currently present in the buffer. Those information now include the size of the loaded and compressed file, which is inferred to be roughly similar to the size kept in memory when pushed.
For segments that are not yet loaded, the attribute corresponding to the Representation bitrate/bandwidth in the Manifest is used instead to estimate it.

---

Now there is a last issue with that strategy: what if no segment of the highest quality can be loaded under the condition of the maxVideoBufferSize? Written in a simpler way: what if even only one segment is already bigger than this limit?
For now, we chose to officially declare this case as leading to an undefined behavior (to avoid having to set things in stones for the next versions) but in reality for now, the RxPlayer also set a minimum buffer size that should be attained (e.g. 5 seconds), which take precedence over the maxVideoBufferSize (so we'll have ~5 seconds of the highest quality instead of e.g. nothing or a lower quality).
We may in the future choose another solution such as lowering the quality in that case.

---

As I'm writing this issue, the feature has already been developed (PR: #1041) and is currently tested.
This issue is just here to have a written trace of that work of the thoughts that led to it.

[peaBerberian]

Done now that #1054 is merged.

Should be released in the v3.27.0 version