…utils dir

Root issue
----------

While working on code refactoring for better taking into account the new
potentially multithread nature of the RxPlayer code (with some files
only running in a WebWorker environment and others only running in a
main thread environment), we recently refactored our file hierarchy
(#1365) to better reflect that new situation. The idea is to make
RxPlayer developpers more aware of what code is intended to run where.

In that work, we had a remaining issue concerning the
`PlaybackObserver`.
This is the part of the code that is monitoring and advertising playback
conditions to the rest of the RxPlayer code. Most core RxPlayer modules
rely on it, in both main thread and WebWorker environments.

The root issue is that the `PlaybackObserver` is a class and thus cannot
be easily transmitted in-between environments (as the main thread and
WebWorker only exchanges between one another through `postMessage`
calls, which follows some rules preventing from doing that).

As such, and only on a multithreaded scenario, the RxPlayer is
serializing in some way the constructed source PlaybackObserver in the
main thread to reconstruct one (the `WorkerPlaybackObserver`) on the
worker.

Because a whole complex PlaybackObserver-compatible structure has to
both be constructed in the main thread and in the worker (yet only the
main thread can act as the "true" source one, because the media element
can only be accessed in main thread), we were asking ourselves where
should we put the common utils (required by both the main thread and
worker) needed to construct one (like the `ObservationPosition` class
and the `generateReadOnlyObserver` util).

Solution 1
----------

This is a first solution proposal, which moves the `PlaybackObserver`
directory outside of the `main_thread` and `core` directories. Instead,
its code is now directly in `src/playback_observer`.

This solution takes inspiration from the `src/mse` directory, which also
exports both:

  1. files intended to be imported when MSE API are present in the
     current environment (when in main thread or when in a WebWorker
     with the MSE-in-worker feature) and

  2. files intended to be imported in environments without MSE.

For example the `src/mse/main_media_source_interface.ts` should __ONLY__
be imported in environments with MSE capabilities. If you do not, you
should import `src/mse/worker_media_source_interface.ts`.

Likewise, I here added a
`src/playback_observer/media_element_playback_observer.ts` file exporting
a `MediaElementPlaybackObserver` structure (new name of the
`PlaybackObserver`) which can only be imported in environements where the
media element is available (so, only on main thread) and a
`src/playback_observer/worker_playback_observer.ts` file which should only
be imported in other environments.

Doing this allows to easily share common utils, in a
`src/playback_observer/utils` directory, without involving the rest of
the RxPlayer code.

Result
------

I'm quite happy with the result, though I get it may seem weird to have
a complex core frequently-running logic part directly in `src` (and not
in `main_thread` or `core` as was the norm) - though it is also the case
of directories like `mse` or `transports`.

RxPlayer code very rarely imported files inside other directories (which
it does here with paths like
`../playback_observer/media_element_playback_observer`) as a way to
push better modularization. Though here it may seem like a feature
because its unusual-ness forces the developper to double check if this
is the right file that is imported.

maxDelay now restrict the value of the delay after that the fuzzFactor
has been applied. This ensure that the returned delay is trully
equal or inferior the the maxDelay.
This would reduce from 3900ms to 3000ms the maxDefault based on our
current config but updating the value does not seem necessary.

…itial failed

While doing some testing on `<UTCTiming>` elements in a DASH MPD, it has
been brought to us that if attempts to load an URL linked to it for the
initial fetch of the Manifest failed (in which case we fallback to a mode
where we don't rely on that element) and if the Manifest has to be
refreshed multiple times, then the URL will be accessed every time the
Manifest is refreshed, even if just one sucessful attempt would be
enough.

The issue was very simple to fix, as it was just that a newly obtained
`clockOffset` - the actual metadata derived from parsing an
`<UTCTiming>` element, was just not actually copied when updating the
base Manifest by its new parsed version.

Once that `clockOffset` is set to the base Manifest, that information
will be communicated to our Manifest parser when refreshed, so it won't
retry to load the clock and continue relying on the one fetched before.

expected retryDelay

Don't re-load a Manifest's optional external resource each time if initial failed

exporting a class with an IIFE change the exported type of the class
from "RxPlayer" to "typeof RxPlayer". That will provoke typechecking
errors for applications that used "RxPlayer" as a type.
This does NOT mess-up with the sideEffects config because
the global overrides, such as "patchWebkitSourceBuffer()" are executed
at the entry point for RxPlayer class (src/index and src/minimal).

fix(test): fix flaky test get_license

…her option

fix(types): remove IIFE to correctly export Player class type

Commit 2744e33
Reorganized the repo and introduce circular dependencies.

fix(demo): text for limit video resolution updates when selecting another options

fix circular dependencies issues.

…n CI

fix: workaround for ps5 to prevent error when closing persistent session

Motivation
----------

Currently, we relied on our WebAssembly MPD parser for two different
scenarios:

  1. performance reasons (on **HUGE** MPD of tens of MB, with a lot of
     `SegmentTimeline` data to parse). Also Relying on WebAssembly here
     instead of DOM parsing led us to much less GC pressure which was also
     a big issue.

  2. Multithread scenarios as the browser's own fast XML parser, `DOMParser`,
     is not usable in other threads.

Though that second scenario only relied on the WebAssembly parser
because it was already written before (and it was because of the first
scenario).
Nothing stops us from relying on a JavaScript MPD parser in Multithread
mode, we only cannot use `DOMParser` there.

Having to provide the WebAssembly code to the `MULTI_THREAD` feature is
a little awkward. We recommend to applications that they use our
"embedded" versions to make it more simple, though it weighs in the 400+KB.
Even if it compresses very very well, it is still a huge file.

It also turn out that WebAssembly is much more recent than the WebWorker
API and as such we're currently not able to rely on the Multithread
mode on very old devices like old smart TV models and old game consoles.
Even worse, an issue in the `v4.0.0-rc.1` made us realize that a device
might be compatible to WebAssembly but might fail to compile it for
various reasons, leading to a fallback to main thread - it would be
better to have a fallback to a JS Parser, like we already have on main
thread today.

It may even make Multithread-only RxPlayer builds (e.g. not having to import
both monothread code and multithread code, just in case multithreading is
not possible) much more doable, which [I guess almost everyone could prefer
for their applications](https://caniuse.com/webworkers).

Thus, relying on a JavaScript parser in a Multithread scenario could be
a very nice feature.

Previous work
-------------

In a previous work (I never made the Pull Request for it yet), I
compiled down the WebAssembly file to JavaScript (through binaryen's
wasm2js util), but it involved a lot of manual maintainance so I quickly
abandonned it (I may re-explore that way in the future). This could have
been nice as it prevented adding yet another MPD parser to the
codebase.

I also made quick tests with dependencies like `fast-xml-parser` but
performances appeared poor so I did not continue in this path.

This solution
-------------

To be perfectly honest, it was only after looking at some Shaka-player
code that I noticed that they now rely on a "txml" dependency for their
XML parsing.
It's actually very recent: shaka-project/shaka-player@7116a34
(the recent-ness of it made me feel that I may be looking at their codebase a
little too much ^^) and it seems to be on their side for performance
reason - very interestingly.

So I looked up that txml thing (repo available here: https://github.com/TobiasNickel/tXml/).
It is a fairly minimal XML DOM parser with a specific focus on speed.
It advertises speed competitive with the native DOMParser API and quite
amazingly it actually was, sometimes it was even faster (though still slower
than our WebAssembly parser).

If this goes very well, we could even imagine doing like the
Shaka-player and completely remove the DOMParser - even opening the way
to also do things like parsing subtitles in a worker. For that, there is
still a lot to do though.

The code was a little hard to integrate through `npm` in a TypeScript
client-side project (for various reasons) so I made the same choice than
Shaka-player by completely copying its code (keeping the licence in the
file) into `src/utils/xml-parser.ts`.

I also had to update its code, this means that code updates on their
side will have to be backported on ours.
However, the code seems to not be much maintained anymore, so this is
not that much of an issue.

Remaining issues
----------------

There are some remaining issues:

  - First I did not yet add parsing for `EventStream` elements nor for
    `SegmentTimeline` elements yet. Both seems doable, and the latter
    will be the real-world test (as it can be incredibly huge on some
    contents).

  - From what I understand from TobiasNickel/tXml#44,
    It doesn't translate entities (like `>` to `>`). This doesn't seem to
    hard to implement though and is rarely important.

Maybe others. There doesn't seem to be a lot of issues (but it doesn't
seem to be a hugely-relied on project either) so I'll look at each of
them in the future.

…irement anymore

DASH: rely on "txml" parser for Multithreading usages

This is an implementation of an idea we had in the past to speed up
asynchronous tests.

Those often depend on some timeout, with a timeout set very high
(hundreds of milliseconds, sometimes seconds) to ensure a test pass even
on the slowest machine running up our tests.

This results in our integration tests taking a lot of time to finish
(more than 30 minutes), even more considering that those are not
parallelized, unlike our unit tests (and doing so is not straightforward
because we rely on a dependency, mocha, as a test runner and on another,
karma, as a browser launcher).

To make it less long, we wondered if we could not rely on another
strategy:
  1. Perform the check almost immediately, on fast computers it has a
     chance of very quickly passing
  2. If the check fails, wait some amount of time and re-perform the
     check.
  3. If the check fails multiple times, it surely means that the current
     device is slow, so we'll wait a longer and longer delay before
     re-performing the check.
  4. If the check still fails after some set time (or 4 seconds by
     default), fail the test.

This is basically another implementation of an "exponential backoff"
algorithm in the player (we already use this type of algorithm at
several places in the player, like for media requests for example).

…ite-spinner

fix(directfile): media with autoplay:false is infinitly in loading state

When doing some hotfixes for our v4.0.0 version, we directly integrated
a browser detection check in the main code of the RxPlayer.

The normal way for the RxPlayer of handling device compatibility, is to
clearly list and document all differences in the `src/compat` directory,
not directly in the main code.

This commit fixes that by giving a name to that work-around, documentating it
and moving it in the `src/compat` directory.

…lat segments

…from-initial-seek-and-play

Remove `isSafariMobile` mention from `main_thread` code.