Set actual duration for dynamic contents whose future end is already known

[peaBerberian]

What to set as a duration attribute of the MediaSource and by extension to the HTMLMediaElement is not that simple.

For static contents (contents that won't evolve with time) like VoD contents, we just set it to the actual known end of the content (technically it is a little more complex as each track might lead to different durations, but still).
However the problem is with dynamic contents which do evolve.

Traditionally, and like many other players, we've set a very high duration attribute when playing dynamic content to prevent encountering side effects of setting that attribute to a lower value, such as not being able to seek to far in the content.

The current HTML WHATWG specification actually recommends setting it to Infinity, but as we've had some issues with that value, we prefer to set it in most cases to 2^32 instead, which has the best result with most platforms.

However when doing those developments, I forgot that there are some cases where the content is dynamic but the actual future end of the content is already known. It can happen with DASH, but it mostly happened with the "local" transport, which allows to play content downloaded locally on the device.

Here a content that was being played while it was still being loaded would report 2^32 through the getVideoDuration API, where we could actually be smarter and set the already-known future end of the content instead.

This commit fixes that.

What it does it to detect when the duration reported by the ContentTimeBoundariesObserver is the actual end of the content, and if it is, indicate it through its durationUpdate event.

This event's payload is then given to the MediaDurationUpdater, which will now know whether this is the actual end or whether setting a very high duration is here preferred.