Add custom tracker support

[defagos]

Pull request

Description

This PR adds support for custom trackers, most notably for analytics or QoS purposes.

Main differences with the PoC implementation

In comparison to our PoC implementation (see #292):

• Trackers are never instantiated by client code. The player manages their full lifecycle. This means that a way to provide initial tracker configuration, if any is needed, must be provided.
• No metadata downcasting is necessary anymore. This ensures trackers can be distributed as standalone components which can be reused by any app.

Changes made

• Add protocol to implement trackers.
• Expose configuration and metadata required by the tracker as associated types.
• Use generics to associate a metadata type with item delivery.
• Introduce adapters as a way to bridge item metadata delivery with metadata required by a tracker in a type-safe manner.
• Extract SRG SSR analytics metadata, currently only logged to the console.

Implementation considerations

• The Source type was superfluous and could be removed. As a result he Player, PlayerItem, Asset and Resource type structure now more closely matches the similar AVPlayer, AVPlayerItem, AVAsset and URL structure found in AVFoundation.
• The AssetMetadata protocol has been added to model item metadata. Control center standard metadata is currently the only requirement associated with this protocol.
• To make the API as easy to use as possible generics have been introduced where appropriate. Type erasure has been applied to avoid type information leaking up to PlayerItem, where such erasure would have led to friction since @Published properties cannot appear as is in a protocol.
• Adapters erase tracker type information at creation type by neatly storing a block which can be later called without knowledge of the tracker type. This way adapters only require a single metadata type in their definition, making the tracker type immediately vanish after instantiation.
• We could improve our PoC idea (see Analytics tracker PoC #292) by avoiding any need for downcasting in the tracker implementation. This approach would not have been acceptable anyway since this would have required a tracker to know about all possible item metadata formats it should handle, breaking separation of concerns. This would namely have prevented separate teams to deliver metadata connectors and trackers independently. The adapter approach therefore provides a neat and type-safe solution to this problem.
• Tracker lifecycle correctness is guaranteed thanks to a resource acquisition is initialization (RAII) approach, a CurrentTracker class type ensuring that the tracker lifecycle is consistent at all times, most notably if the player is deallocated during playback.
• Ergonomic helpers have been introduced to work with item trackers having no associated configuration or metadata.
• The low-level system player has been exposed so that integration with 3rd party trackers requiring access to it is possible.

Afterword

• With custom tracker support implemented the initial Pillarbox vision is now complete. Pillarbox is now a fully flexible player creation ecosystem (metadata, playlist, analytics, UI). The sky is the limit 🙂.
• We ensured that playback is not interrupted during metadata updates which do not alter the resource URL. If the resource URL is changed Pillarbox automatically resumes playback with the new resource without stopping playback, unlike Letterbox. So we can consider that kill switch support is automatically guaranteed without additional work.

I updated the dedicated Letterbox idea thread accordingly, as many open questions have now found an answer.

Checklist

• APIs have been properly documented (if relevant).
• The documentation has been updated (if relevant).
• New unit tests have been written (if relevant).
• The demo has been updated (if relevant).
• The playground has been updated (if relevant).