Fine grained rate-limits

[jcgruenhage]

acmed currently allows setting rate limits on endpoints, that specify how many
requests can be made per interval. It does not take the kind of request that is
made to the endpoint into consideration, which means that the rate limits
actually set by CAs (see https://letsencrypt.org/docs/rate-limits/) can not
really be represented by this.

My suggestion is to extend the current mechanism by giving rate-limits an
optional scope. This scope can be the path in the HTTP request, a path prefix,
an ACME resource (as listed in the directory response), etc. A request is then
only blocked, if there is a currently blocking rate-limit on that endpoint, that
matches this request. The specifics on how to model that and how to expose the
configuration for this aren't trivial, but I think if at least path (prefixes)
and ACME resources can be used as a scope, a few important rate limits can now
be set properly, that couldn't be set before, like the one for the newOrder
resource (300/3h), a shared one for the ACME resources newNonce, newAccount,
newOrder and revokeCert (20/1s), and the one for /directory
and anything under /acme (40/1s).

Even after that, there is a bunch of limits that this doesn't catch, but it'd be
a big improvement over the status quo.

[jcgruenhage]

I've started looking at this from an implementation side for a bit here. Combining multiple rate-limits is a bit tricky apparently, looking at different implementations (like https://lib.rs/crates/htb and https://lib.rs/crates/governor) they either don't implement them (see boinkor-net/governor#156), or not in a way that's flexible enough for us (htb says that buckets need fixed parents, which makes configuring this a lot less versatile than what I've described above).

I'll take a deeper look at some point, but I won't continue here tonight.

[jcgruenhage]

Sleeping over it: Maybe it makes more sense to go for an implementation that somewhat works first before going for an implementation that works perfectly. For now, that will just mean that I'll be waiting for a positive outcome on each of the limits that match a request in sequence, ordered by the refill rate (from slow to fast), which is a good enough approximation IMO.