Remove shaka.cast APIs, have UI talk directly to generic receivers

[joeyparrish]

Have you read the FAQ and checked for duplicate open issues?
Yes

Is your feature request related to a problem? Please describe.

The Shaka cast APIs predate the Cast Application Framework (or at least our awareness of it). Senders using shaka.cast APIs must also have receivers using shaka.cast. Shaka-based senders that use CAF-based receivers would have to bypass our cast APIs.

Describe the solution you'd like

We should drop the shaka.cast APIs and have the Cast button in the UI talk directly to the Cast SDK and to generic receivers. This could (maybe) be done in a backward compatible way if we keep the shaka.cast APIs for a while, either by detecting which SDK is loaded on the sender (v2 or CAF), or by a UI config. But it might be better to make the breaking change upfront and release it as v5 later this year.

Additional context

Related issues:

• Support touch controls when casting to Smart Displays #2635 (touch controls not working because we use an old SDK instead of CAF)
• Is it possible to send customData? #4133 (unable to use customData field from Shaka-based sender to CAF-based receiver)

[g-silva-oliveira]

Hello fellows. first of all thank you for this amazing project. Have you any upgrade about this issue?

[joeyparrish]

No, no update. When we have an update, you'll see it here. Nobody is working on this yet.

[joeyparrish]

I'll be working on this in the near future. If I run into issues on the receiver side or issues that require a continued reliance on custom messaging, I may have to pause the project.