Not entirely sure why it was exposed in the first place. Most uses with
it essentially boiled down to mis-usage when they meant to use the
/messages endpoint (via Client.logs_from or Messageable.history) or
complaining about the partial data woes that came from it.
This is a breaking change.
1. Change on_guild_emojis_update to have 3 arguments.
- The first parameter is now the guild object
2. Remove on_channel_create, on_channel_delete, and on_channel_update
- They are now split into two.
- on_guild_channel_[create|delete|update]
- on_private_channel_[create|delete|update]
3. Change on_member_ban to allow User.
- (member) -> (guild, user)
- user can also be a Member
This now sort of respects "Awaiting Endpoint..." waiting. I haven't
actually tested out this case since it's hard to get it. However this
new code does work with the regular connection flow.
This is a complete redesign of the old voice code.
A list of major changes is as follows:
* The voice websocket will now automatically reconnect with
exponential back-off just like the regular Client does.
* Removal of the stream player concept.
* Audio now gracefully pauses and resumes when a disconnect is found.
* Introduce a discord.AudioSource concept to abstract streams
* Flatten previous stream player functionality with the
VoiceClient, e.g. player.stop() is now voice_client.stop()
* With the above re-coupling this means you no longer have to
store players anywhere.
* The after function now requires a single parameter, the error,
if any existed. This will typically be None.
A lot of this design is experimental.
This shows the Shard ID in more places, along with a gateway trace and
session ID. Also helps show the RESUME/IDENTIFY/RESUMED/READY flow a
bit more instead of it looking like the connection has zombied out.
WeakValueDictionary cleans up too late and brings too little benefit.
Also clean up the state when the first READY is encountered for
AutoShardedClient and when any READY is encountered in regular Client.
There is potential that when recreating the Emoji list in the
GUILD_EMOJIS_UPDATE event would just fetch from cache and the element
in cache having an out of date Guild reference. This Guild reference
will be kept alive for longer than it should be.
By always overwriting the Emoji reference, this problem goes away.
The library had a memory leak in the case using the global emoji cache.
When the bot would leave the guild, the Emoji would maintain a strong
reference to the Guild keeping them alive along with the entire state
associated with it.
Hopefully this means when the bot has some lingering object for
whatever reason, the memory doesn't double due to it having a strong
reference to an outdated connection state.
