Proposal: ContentInitializer: remove explicit two-steps of prepare and start

[peaBerberian]

Since we brought the idea of allowing a PlaybackObserver to be without a media element attached (e.g. when a previous content is still not stopped), we have an occasion to simplify the ContentInitializer API a little:

Instead of having two methods prepare (non-destructive content preparation, e.g. manifest fetching) and start ("destructive" playback, in that the previous content will be stopped), we can now just have one exposed API and make it itself await for media element attachment to know when it's able to actually play.

i.e. instead of:

const init = new ContentInitializer({ /* ... */ });

const playbackObserver = new PlaybackObserver({ /* ... */})
// ... Link callbacks to `init` events.

init.prepare();

// ... Stop previous content

playbackObserver.attachMediaElement(mediaElement);

// ... Ensure media element is ready to play a new content -
// (specifically clean some DRM state if needed)

init.start(mediaElement, playbackObserver);

We can now just do:

const init = new ContentInitializer({ /* ... */ });

const playbackObserver = new PlaybackObserver({ /* ... */})
// ... Link callbacks to `init` events.

init.start(playbackObserver);

// ... Stop previous content

// ... Ensure media element is ready to play a new content -
// (specifically clean some DRM state if needed)

playbackObserver.attachMediaElement(mediaElement);

(preprare is renamed start, old start is removed, attachMediaElement is just done later).

Though this does mean a supplementary PlaybackObserver method - here called onMediaElementAttachment(callback, cancelSignal) that the ContentInitializer has to know about and call. This also means that it now understands the idea that a PlaybackObserver might not have a media element attached at first.

Also playbackObserver.attachMediaElement() now needs to be called only once the media element can actually play a content, not just when its properties seem clean enough. But IMO for that part, it's cleaner and more understandable that way than before.

---

Note that even if it can look like it, this is not at all linked to our potential "preload" feature.

This is just a possible alternative ContentInitializer API that I wanted to illustrate since we did the
"PlaybackObserver-without-media-element" thing.

[github-actions]

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

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	35.88ms -> 36.77ms (corrected: -0.900ms, A/A bias: 0.012ms, z: 0.23094)	29.80ms -> 29.80ms (corrected: -0.300ms, A/A bias: 0.300ms, z: 1.47224)
seeking	171.42ms -> 161.41ms (corrected: -2.451ms, A/A bias: 12.456ms, z: 0.13472)	11.60ms -> 11.80ms (corrected: -0.125ms, A/A bias: 0.050ms, z: 0.75537)
audio-track-reload	31.62ms -> 32.28ms (corrected: -0.788ms, A/A bias: 0.127ms, z: 0.81791)	30.60ms -> 30.70ms (corrected: 0.050ms, A/A bias: -0.100ms, z: 0.18283)
loading over active content	22.21ms -> 22.39ms (corrected: -0.664ms, A/A bias: 0.491ms, z: 0.70244)	20.70ms -> 20.75ms (corrected: -2.025ms, A/A bias: 0.925ms, z: 0.70244)
large multi-period manifest	94.07ms -> 93.94ms (corrected: -0.119ms, A/A bias: 0.249ms, z: 0.01925)	84.10ms -> 86.70ms (corrected: -0.300ms, A/A bias: -0.975ms, z: 0.01925)
cold loading multithread	51.92ms -> 53.98ms (corrected: -2.319ms, A/A bias: 0.256ms, z: 0.29830)	50.40ms -> 49.80ms (corrected: 0.750ms, A/A bias: 0.050ms, z: 2.40563)
seeking multithread	101.04ms -> 91.09ms (corrected: 24.759ms, A/A bias: -14.801ms, z: 0.65433)	13.30ms -> 13.40ms (corrected: -0.425ms, A/A bias: 0.325ms, z: 1.59252)
audio-track-reload multithread	30.70ms -> 30.44ms (corrected: -0.359ms, A/A bias: 0.617ms, z: 0.88527)	29.70ms -> 29.60ms (corrected: -0.325ms, A/A bias: 0.475ms, z: 0.82754)
hot loading multithread	20.58ms -> 20.41ms (corrected: -0.057ms, A/A bias: 0.222ms, z: 0.21651)	19.70ms -> 19.40ms (corrected: 0.100ms, A/A bias: 0.125ms, z: 0.66876)