REST rate limiting

[ljedrz]

This PR introduces a rate limiting service (with a limit of 5 reqs/s) to the REST server.

[howardwu]

Can this be per IP?

[howardwu]

^This was Github. Sorry, I don't know why these "auto-closes" keep happening. In snarkVM, the branches usually retarget, rather than closing.

[niklaslong]

(pending the per IP Q)

[ljedrz]

Can this be per IP?

There is a crate that facilitates this, but it doesn't seem like it's widely used or well-maintained; the current version is 0.0.4 and the last commit is from 6 months ago.

[howardwu]

Would it be inefficient/unwise for us to implement our own?

It seems we can use an LRUMap on 100K IPs, and track each IP's last n request timestamps, where n is 5 * 60 for 5 req/s averaged over 60 seconds (to give tolerance for bursty activity, potentially from network latency or scheduler latency)

[howardwu]

Args, this is once again an auto-close by Github. A unique issue to only this repo.

[joske]

and again :-D

[howardwu]

@ljedrz I think we have RPS rate limiting now. Is this PR tangential?

[howardwu]

#2942 says that this PR may be complementary. Can you add some color?

[ljedrz]

The rate-limiting in this PR is not related to the source IP - it's a limit applicable to the entire REST server, to avoid a DDoS angle. However, if we are content with the limits we impose per IP, it may be redundant. We can always return to this if we have a stress test that executes many REST requests from unique source IPs, and determine that it's needed.

[howardwu]

@ljedrz can you resolve the merge conflicts and set this limit to be at 100 requests per second?

For reader's context: snarkOS includes a per IP rate limiter that can be set as a CLI argument. By default, this is set to 10 requests per second (RPS) on a per IP basis. This PR is mean to limit the total requests across all IPs as an upper bound.

[ljedrz]

Cc https://github.com/AleoHQ/snarkOS/issues/3190 for that one unrelated CI failure.