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 2cc51fd2f94bb123bab08c2d0506d67693ad04a1 with the base branch dev.

Details

Performance tests 1st run output

No significative change in performance for tests:

Name	Mean	Median
loading	22.02ms -> 22.15ms (-0.127ms, z: 0.20924)	31.05ms -> 31.05ms
seeking	14.91ms -> 14.24ms (0.671ms, z: 0.59502)	12.30ms -> 12.30ms
audio-track-reload	29.22ms -> 29.10ms (0.127ms, z: 2.27246)	42.75ms -> 42.60ms
cold loading multithread	49.35ms -> 48.44ms (0.909ms, z: 11.72658)	72.60ms -> 71.25ms
seeking multithread	65.62ms -> 56.32ms (9.295ms, z: 0.58050)	11.25ms -> 11.25ms
audio-track-reload multithread	28.32ms -> 28.28ms (0.038ms, z: 0.62712)	41.70ms -> 41.55ms
hot loading multithread	16.55ms -> 16.42ms (0.134ms, z: 4.46823)	24.30ms -> 24.00ms