[Feature Request]: run frequently enough that ARI retry caching matters

### What problem does this feature solve or what does it enhance?

On client behavior, the ARI spec says:

> Clients MUST attempt renewal at a time of their choosing based on the
> suggested renewal window. The following algorithm is RECOMMENDED for
> choosing a renewal time:
>
> 1. Make a renewalInfo request to get a suggested renewal window.
>
> 2. Select a uniform random time within the suggested window.
>
> 3. If the selected time is in the past, attempt renewal immediately.
>
> 4. Otherwise, if the client can schedule itself to attempt renewal
> at exactly the selected time, do so.
>
> 5. Otherwise, if the selected time is before the next time that the
> client would wake up normally, attempt renewal immediately.
>
> 6. Otherwise, sleep until the time indicated by the Retry-After
> header and return to Step 1.
>
> In all cases, renewal attempts are subject to the client's existing
> error backoff and retry intervals.
>
> In particular, cron-based clients may find they need to increase
> their run frequency to check ARI more frequently. Those clients will
> need to store information about failures so that increasing their run
> frequency doesn't lead to retrying failures without proper backoff.
> Typical information stored should include: number of failures for a
> given order (defined by the set of identifiers on the order) and time
> of the most recent failure.

### Proposed Solution

As the spec says, we should store information about failures, so running more frequently doesn't lead to retrying failures without proper backoff.

As such, we should store:
- number of failures for a given order
- time of the most recent failure

These will let us calculate the next time to retry after failure.

Also, we should store the retry-after header value, and not check ari again until after that time.

These could potentially be two separate PRs.

### Alternatives Considered

_No response_