Not overly proud of this implementation but this allows the library
to differentiate between a 4014 that means "move to another channel" or
"move nowhere". Sometimes the VOICE_STATE_UPDATE comes before the
actual websocket disconnect so special care had to be taken in that
case.
Fix#5904
The previous code would check zombie connections depending on whether
HEARTBEAT_ACK was received. Unfortunately when there's exceeding
backpressure the connection can terminate since the HEARTBEAT_ACK is
buffered very far away despite it being there, just not received yet.
This slows down chunking significantly for bots in a large number of
guilds since it goes down from 75 guilds/request to 1 guild/request.
However the logic was rewritten to fire the chunking request
immediately after receiving the GUILD_CREATE rather than waiting for
all the guilds in the ready stream before doing it.
This should work both on Windows and on Linux.
Apparently these types of blips are considered normal for Discord. So
rather than letting the reconnect logic handler expect these to be
catastrophic, it should handle it specially so it doesn't waste an
IDENTIFY for what ultimately should just be a small networking blip.
This also makes it less noisy for the end-user as these complaints
happen from time to time.
This uses the nonce field to properly disambiguate queries. There's
also some redesigning going on behind the scenes and minor clean-up.
Originally I planned on working on this more to account for the more
widespread chunking changes planned for gateway v7 but I realized that
this would indiscriminately slow down everyone else who isn't planning
on working with intents for now.
I will work on the larger chunking changes in the future, should time
allow for it.
This prevents our sessions from being invalidated by Discord which
caused a lot of failures when resuming. This caused an unnecessary
amount of IDENTIFYs to happen depending on the circumstances.
Closes#2631
See also discord/discord-api-docs#1472
Probably not a significant difference but might as well use it here.
The basic idea is to cache the getattr calls instead of repeatedly
doing it (since they're around 105ns on my machine). The dictionary
lookup is about 41ns on my machine.
The next step in speeding up library code some more should be in
the parser bodies themselves but that's a problem to tackle another
day.
