Add MetadataState to :ui:compose

[MGaetan89]

This commit introduces MetadataState, a Compose state that exposes metadata information about the current MediaItem. At the moment, it only provides the media uri.

[oceanjules]

I'm going to send this for internal review now. You may see some more commits being added as I make changes in response to review feedback. Please refrain from pushing any more substantive changes as it will complicate the internal review - thanks!

[MGaetan89]

@oceanjules I see that you have pushed the new listenTo extension. Is it fine if I update this PR to use it?

[oceanjules]

@MGaetan89 yep, go for it! Although the CL in its current shape and form is still under internal scrutiny at the moment, so a listenTo fix will not necessarily help push it forward, sorry. Multiple problems here, but largely broken down into: 1) shouldn't flatten MediaItem into primary fields (like localConfiguration.uri to simply uri) and 2) should group logical Player data into larger state holders (maybe one that will hold information beyond MediaItem and MediaMetadata).

I understand that this CL was not even on the original plan (GL surface type brainstorm is also happening in internally) and now it's blowing up into a whole design discussion, but please bear with us while we design maintainable and reusable Compose blocks.

[MGaetan89]

yep, go for it!

Done 👍🏻

Although the CL in its current shape and form is still under internal scrutiny at the moment, so a listenTo fix will not necessarily help push it forward, sorry.

No worries, I am not in a hurry to have this merged 🙂

Multiple problems here, but largely broken down into: 1) shouldn't flatten MediaItem into primary fields (like localConfiguration.uri to simply uri) and 2) should group logical Player data into larger state holders (maybe one that will hold information beyond MediaItem and MediaMetadata).

I understand that this CL was not even on the original plan (GL surface type brainstorm is also happening in internally) and now it's blowing up into a whole design discussion, but please bear with us while we design maintainable and reusable Compose blocks.

Thanks for the insights! I wasn't expecting this change to go through easily. This new state probably needs to have a broader purpose, rather than just exposing a URI as a shortcut.
Anyway, let me know if I need to make any change here once the design decision has moved forward, or if I can be of assistance in any way.

[bubenheimer]

2. should group logical Player data into larger state holders (maybe one that will hold information beyond MediaItem and MediaMetadata).

Ultimately it should be a single (snapshot) Player state to stop fighting the (Compose) framework for eternity.

[oceanjules]

I will close this PR due to the recent addition of a2f071d. In a nutshell, we decided that "only metadata" state holder was probably too narrow of a scope, whereas "a whole timeline" state holder was too broad (although we will soon publish something like a PlaylistState). Also, we decided not to flatten the mediaitem's nested structure (i.e. bringing the uri out of localConfiguration onto the top level of some UI state holder class).

Hopefully, you can get all the necessery information out of CurrentMediaItemState.mediaItem. I know this whole change was only motivated by #2619, so if you rebase that on the latest main, we could have a discussion about using reflection and exoplayer in our new modules.