ACMEv2: Implement orders per time window rate limit

[cpu]

After #3402 lands we're left calculating the pending order rate limit by fetching all unexpired orders for an account, and then fetching each associated authorization. We should batch the authorization lookup and try to ensure this rate limit implementation is optimized.

After submitting a PR for this issue it was decided that we shouldn't have a pending order rate limit as proposed here and implemented in master:

Instead:

Rather than a limit on pending orders, why not a limit on the overall orders created per time window (pending or not).
So, for this we would probably have to add the created column I suggested, plus an index on it

[jsha]

One thing I thought of last night: What if we don't need a pending order limit after all? Now that we're planning to not reuse pending authzs, each new order will create a minimum of one new authz. So eventually you would be prevented from creating new orders because you'd hit the pending authz limit.

[jsha]

Plan: We can query for orders that have a nil certificate serial and a nil error, which means they are either pending or processing. It's fine for this rate limit to apply to processing certificates, since none should stay in that state long. We'll need a new index.

[cpu]

@jsha One problem with the proposed plan: If an authz associated with an order is deactivated, we consider the order deactivated when calculating the status since there's no way to "reactivate" or otherwise complete the order. The approach of finding unexpired orders with a nil certificate serial and a nil error would include deactivated unexpired orders against the rate limit :-/

I'm not sure what the best approach is to address that - maybe its fine? Authz deactivation is primarily to save pending authorization rate limit space or to force revalidation for future issuances. We could add a field to the order that we set when an authz is deactivated but it means looking up each order an authz is associated with at the time of a deactivation and updating that field which might be a non-trivial amount of work.

[jsha]

Let's consider it fine for now. It's kind of an accident of semantics that the pending authz limit can be fixed by deactivating authzs. Changing an authz to deactivated doesn't really save us any resources. It's been convenient for when people get stuck in a rate limited state, but then we drastically reduced the problem of pending authz limiting through reuse of pending authzs... hopefully pending order reuse will have the same effect in v2.

[cpu]

Sounds good. Authz deactivation is a place in the ACME spec that got complicated by the addition of the order based issuance flow and the spec doesn't explicitly address how they interact. There's no order deactivation POST like there is for authorizations and there's no text that says what should happen to an order if one or more of its associated authorizations are deactivated. I think it would be worth finding time soon to start an ACME WG thread clarifying order object status in general and the lifecycle of an order.

[jsha]

I agree that's a good idea. Also, it's worth mentioning that we can be more flexible about the time window for pending order rate limiting than for pending authz rate limiting; for pending authz, we were limited by the available indexes and so had to make the window the same as the expiration time. We can make sure that's fixed for orders. The long time window is a big part of why pending authz limiting was so painful.

[cpu]

I edited this issue's title/description to reflect the fact that the task has completely changed from what the issue originally called for based on the discussion in #3438.