Fix resource loading conflicts with playlist management

[defagos]

As a user I want a good user experience with any kind of content.

Acceptance criteria

• Playback starts fast.
• Playback never unexpectedly continues in background after closing the player.

Hints

A custom resource loader was implemented in #60 to load content from URNs and deque playlist support was added with #76. When combined these two features show several issues:

• On iOS 16.0 navigating back does not work (navigation is made forward). This works on iOS 16.1 but maybe this is not an actual iOS issue but rather an artefact of our implementation, leading to unreliable behavior.
• When adding some delay to the media composition pipeline (e.g. 4 seconds) playback only starts when resource loading requests for all items in the playlist have been made. Loading the item from an asset with automaticallyLoadedAssetKeys set to ["playable"] makes the player start early but, if the player is closed while some items are still not loaded, the player continues to play in the background until all pending resource loader requests have been processed.

Remarks:

• We could share resource loaders among items (lazy instantiation and reuse, per environment).
• Resource loading cancellation is not called often it seems.
• The issue seems similar to those we sometimes experience with Letterbox after closing the player, still hearing the sound for a while. Letterbox also stores the item internally and has a resource loader working in a similar way so we might find a way to improve Letterbox at the same time.

Tasks

Probably better investigated in a project implemented from scratch. An idea:

• [x] Mitigate reported resource loader issues.
• [x] Check memory and network profile.
• [x] Make PR for Letterbox if an improvement is found.
• [x] Check UT resilience if automaticallyLoadedAssetKeys is empty.
• [x] Check if AVAssetResourceLoadingContentInformationRequest can be meaningfully filled.

[defagos]

Some learnings and checks:

• Cancelling delayed publishers works as expected and does not lead to dangling publishers, so the approach applied to simulate slow requests is not responsible of creating the reported issue.
• As documented AVAsset.cancelLoading() does not cancel resource loading but only asynchronous property loading.
• The fact that playback takes more time to start when using AVPlayerItem.init(asset:) is to be expected, as the default behavior without automaticallyLoadedAssetKeys parameter is to wait until the duration is known. Using AVPlayerItem.init(asset:automaticallyLoadedAssetKeys:) with better parameters (or none) is therefore key to ensure fast startup, especially since we can use property publishers to observe each required property in a very simple way anyway.

[defagos]

Even though AVAsset.cancelLoading() does not cancel resource loading failing to do so leads to the reported lengthy cleanup time when closing the player while only part of the resources have been loaded (likely because some implicit async property retrieval is still pending). The player is still deallocated early so performing this call in deinit fixes the issue.

Calling AVPlayerItem.cancelPendingSeeks() is likely good practice as well.

[defagos]

SRG Media Player already calls -[AVAsset cancelLoading] so no improvement PR can be made. Remaining issues in Letterbox likely have another cause.

[defagos]

I checked with LLDB (breakpoint + printing $arg4) that AVPlayerItem.init(url:) calls AVPlayerItem.init(asset:automaticallyLoadedAssetKeys:) with ["duration", "availableMediaCharacteristicsWithMediaSelectionOptions"] as automatically loaded asset keys.

If we want to minimize the number of keys automatically loaded before the item is ready to play we should introduce a convenience constructor.

[defagos]

I doubt AVAssetResourceLoadingContentInformationRequest can be filled in a meaningful way, as we are not getting media data, rather only the playlist (provided as a redirect).

[defagos]

Tests work fine if we load items without automaticallyLoadedAssetKeys (checked with a global find & replace; won't be tested automatically since would add only noise).

[defagos]

~Resource loader issues described in this issue are not related to our implementation (according to what I know after investigating the topic further)~

Resource loading issues were ours, see #116, but still there are issues on iOS 16.0 which cannot be our own (automatic item chaining of AVQueuePlayer can struggle to resume playback). So we should bump the minimum OS version later, see #79.