The Limiter API has been adjusted significantly to both improve both safety and ergonomics and two Limit types have been corrected to match the legacy implementations.

Safety
Previously, the key used for looking up limit overrides and for fetching individual buckets from the key-value store was constructed within the WFE. This posed a risk: if the key was malformed, the default limit would still be enforced, but individual overrides would fail to function properly. This has been addressed by the introduction of a new BucketId type along with a BucketId constructor for each Limit type. Each constructor is responsible for producing a well-formed bucket key which undergoes the very same validation as any potentially matching override key.

Ergonomics
Previously, each of the Limiter methods took a Limit name, a bucket identifier, and a cost to be spent/ refunded. To simplify this, each method now accepts a new Transaction type which provides a cost, and wraps a BucketId identifying the specific bucket.

The two changes above, when taken together, make the implementation of batched rate limit transactions considerably easier, as a batch method can accept a slice of Transaction.

Limit Corrections
PR #6947 added all of the existing rate limits which could be made compatible with the key-value approach. Two of these were improperly implemented;

• CertificatesPerDomain and CertificatesPerFQDNSet, were implemented as
• CertificatesPerDomainPerAccount and CertificatesPerFQDNSetPerAccount.

Since we do not actually associate these limits with a particular ACME account, the regID portion of each of their bucket keys has been removed.