Yield Break from RetryState::wait() on last iteration

[djc]

As suggested by @christianhoelzl in #116 (comment):

One option is to preemptively end the retry if the next iteration would exceed the timeout. This is how acme4j does it.

Doesn't really solve the original problem I highlighted, let's discuss here:

Uhh, not sure how this interaction [between timeout and retry-after] will work? Seems like a strong chance the server might yield a Retry-After of more than the timeout set here, which means we'll only ever try once...

[christianhoelzl]

That problem seems more in scope of the application that uses instant-acme. Not to retry only once, the application could enter a pending state and retry an certificate enrollment from scratch not before the given Retry-After date-time. For example if the CA does not issue certs the next days because you requested too many recently. If the application can observe the Retry-After value with the instant-acme api, then an application has the data at hand to handle this temporary error condition. Maybe extend types::Error::Api to yield the Retry-After header?

[djc]

That problem seems more in scope of the application that uses instant-acme. Not to retry only once, the application could enter a pending state and retry an certificate enrollment from scratch not before the given Retry-After date-time. For example if the CA does not issue certs the next days because you requested too many recently. If the application can observe the Retry-After value with the instant-acme api, then an application has the data at hand to handle this temporary error condition. Maybe extend types::Error::Api to yield the Retry-After header?

Yielding a specific error variant seems like a decent potential way out of this problem...

@cpu thoughts?

[cpu]

Yielding a specific error variant seems like a decent potential way out of this problem...

That sounds reasonable to me 👍 I agree with @christianhoelzl that this feels like a place where higher level application logic should take-over.