Gateway ratelimiting

[Kraigie]

Currently there is no ratelimiting on requests sent over the gateway.

It would be somewhat trivial to implement ratelimiting using GenStage, such that only x amount of events are sent in a given time frame.

For Consideration

If we decide to use GenStage, there are a couple things we need to consider

Differing ratelimits

Different types of messages have different ratelimits that we need to respect. This makes it a little more complicated as we need to do some sort of partitioning and/or spawn multiple consumers.

Priority

We want to be able to give certain messages a priority over others (I.E. we want to handle heartbeats before we send member requests). Given that we will likely not be storing demand in memory, we can develop some kind of naive priority queue to handle this for us.

TODO:

• [ ] Implement
  • [ ] Differing ratelimits
  • [ ] Priority

[cookkkie]

Isn't it cleaner to throw if the ratelimit is exceeded? And let the sender handle the retry?

[BobbyMcWho]

Could you use Semaphore to track requests and fail fast when the rate limit has been hit?

[queer]

Given how the gateway ratelimiting is fairly simple, it'd probably make more sense to just use something like https://github.com/ExHammer/hammer

[jchristgit]

We can use (a much simpler method of) the state machine-based approach from #501 to implement this in a relatively simple manner, as the gateway ratelimit is per-connection.

For the session start limit, we will need something different to coordinate it across multiple nodes - likely this belongs to a separate issue. See https://discord.com/developers/docs/topics/gateway#sharding-max-concurrency.

I am planning this for 0.9.