The difference in speed seems negligible at start up, which is when
most time is taken for actually parsing JSON. I could potentially be
missing something but profiling didn't point to any discernable
difference.
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.