Improve chromecast disconnection logic

[OttoWinter]

Description:

The latest cleanup to the cast platform introduced a weird bug where disconnecting from the old leader of a cast audio group was not handled correctly.

In particular, cast group leaders don't like accepting connections as long as there are open sockets to the old leader. In the old code, we would do a non-blocking disconnect and not join the socket client thread. So we tried connecting to the new leader before the old leader was disconnected. This prevented us from connecting to cast groups on every second leader change.

Apparently, async_will_remove_from_hass is not called on EVENT_HOMEASSISTANT_STOP. With the assumption that this seems to be intended (feels weird to me), I manually added a listener to the event bus.

If there's a 68.1 release, it might be good to maybe include this PR. It's not a huge code change and I spent the last few days testing this change.

Related issue (if applicable): fixes #13530

Example entry for configuration.yaml (if applicable):

media_player:
  - platform: cast

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[balloob]

I think that registering a HOME_ASSISTANT_STOP event listener, like you did, is a better approach than using the removed from hass hook. Because cleanup during runtime is different than cleanup during shutdown.