This PR makes many of the types under `EventContext` separate `#[non_exhaustive]` structs. This makes it more feasible to add further information to connection and packet events as required in future. On this note, driver (re)connection events now include the SSRC supplied by Discord and the domain name which was connected to.
In addition, this fixes global timed events to return a list of all live tracks, and extensively details/documents events at a high level.
This was tested using `cargo make ready`.
Knowing your own SSRC is useful for handling RTCP packets, which may detail information about *ourselves* rather than another host. In theory, at least: this confirms that Discord just sends ReceiverReports containing your own packet stats.
This would have been better to fit into Driver(Re)Connect, but that would be a breaking change: when this change is made, `SsrcKnown` shall be deprecated.
These should allow bots to hook up events to a variety of important connection events as required. This was primarily motivated by the user who raised dcb6ad9.
Although I really would have liked to squeeze in (finite) reconnection attempts with exponential backoff, so that automated repeat attempts could be neatly handled, `Config` was accidentally *not* made non-exhaustive. Adding this and its needed configuration would then be a breaking change. This should warn users about an accidentally dead connection, until the next version can be put forth.
Far cleaner and more reliable than the old doc-link pattern. Also allowed me to spot some event types and sources which should have been made non_exhaustive.
This implements a proof-of-concept for an improved audio frontend. The largest change is the introduction of events and event handling: both by time elapsed and by track events, such as ending or looping. Following on from this, the library now includes a basic, event-driven track queue system (which people seem to ask for unusually often). A new sample, `examples/13_voice_events`, demonstrates both the `TrackQueue` system and some basic events via the `~queue` and `~play_fade` commands.
Locks are removed from around the control of `Audio` objects, which should allow the backend to be moved to a more granular futures-based backend solution in a cleaner way.
