Playback of tracks stops when moving channel

[FelixMcFelix]

Songbird version: 0.4.x

Rust version (rustc -V): N/A

Serenity/Twilight version: Any

Output of ffmpeg -version, yt-dlp --version (if relevant): N/A

Description: Bots do not seem to correctly resume after being moved from one channel to another. Ideally, the logical flow here should be:

• Bot begins move from one channel to another. Driver state (live tracks, inputs, trackstate, event handlers) are kept intact.
• Playback ceases, session moves to idle state.
• Connect to the new channel over WS, open a UDP socket handle. Pass connection state to scheduler and promote call to active if it should be in this state.
• Playback resumes exactly where it left off.

This is how songbird functioned without issue pre-0.4.x. To my knowledge, state is being carried between channels as it always has been. However, no tracks will play nor will audio be generated... until an event is sent to a live track or a new track is added. I suspect there is an issue with the scheduler moving a session from Idle into Active during the above sequence of events.

Steps to reproduce:

1. Join a given channel.
2. Play one or more Tracks.
3. Move bot to another channel using join, making sure not to remove the original Call/Driver pair.

[FelixMcFelix]

The problem is down to how any task without a live connection is demoted from Live to Idle. This is expected and correct, and serves the dual function of pausing present tracks. However, we then trigger promotions using the following check on messages sent to the Mixer:

https://github.com/serenity-rs/songbird/blob/1b98c307466875cb72306d71c97abb38afd50a48/src/driver/tasks/message/mixer.rs#L42-L46

The new connection is filled in using MixerMessage::SetConn, which will not trigger promotion. However, when fixing this we need to take extra care with SetConn to restore the forwarding task if no promotion occurs, and we need to take care that no messages are lost on the main channel.

[FelixMcFelix]

Closed by #222.