feat(web): chromecast support

[etnoy]

Cast your photos and videos from the web client!

This PR isn't finished but I need your help to test and clean up.

TODO:

• Styling the cast button, ensure dark/light mode
• Styling the video playback controls
• Refactor and code cleanup
• Authentication currently sucks, maybe we should just use the current session token?
• The cast button has a hard time showing up in the timeline, but it shows up nicely in the asset viewer

I'm sure there are better ways to communicate reactive data from the cast sender. Runes?

[omricarmel]

Having this key created ad hoc is good but not enough. cast keys should be ephemeral and scoped bc they are handed over to the cast device. The cast device is inherently untrustable bc it is meant to be a common device sometimes in a public space.

Also the cast device should not have the view context of the current user.

A possible solution is to create an ephemeral "cast" shared album (instead of "cast" key) scoped with the photos in the cast session (added upon request) and deleted on session end with a possible expiry limitation.

[etnoy]

Yes, this is just the initial ad-hoc implementation. We were just discussing today in the discord how to get this better before merging the PR. Obviously this must be improved. One idea is to use jwt tokens with decent duration to send with the URL instead of the current API keys

[omricarmel]

jwt is interesting but does the server already have support?

creating a cast album may open the door to cast queues and even shared queues similar to youtube's casting.
also takes care of asset access scope. adding a key (riding on the password mechanism of shared album) and attaching the credentials to the cast device session could be a nice addition.