Directory errors obscured

[Sheldon Hearn]

Recently we started running into the following error with increasing frequency:

Acme::Client::Error::UnsupportedOperation: Directory at https://acme-v02.api.letsencrypt.org/directory does not include `new_order`
/usr/src/app/lib/acme/client/resources/directory.rb:27:in `block in endpoint_for'
/usr/src/app/lib/acme/client/resources/directory.rb:26:in `fetch'
/usr/src/app/lib/acme/client/resources/directory.rb:26:in `endpoint_for'
/usr/src/app/lib/acme/client.rb:357:in `endpoint_for'
/usr/src/app/lib/acme/client.rb:131:in `new_order'

The line numbers in directory.rb can't be trusted, because they come from a patched version of same. We guessed that directory.rb was ignoring the fact that it had received an API error, so we instrumented it to include the HTTP response as a custom property on the UnsupportedOperation.

Here is what we got:

HTTP 403
{"type": "urn:ietf:params:acme:error:rateLimited", "detail": "Your IP, x.x.x.x, has been blocked due to extremely high traffic. Once corrected, request a review by emailing [e-mail]"}

Looks like the at least the error detection aspect of the Faraday middleware should be applied to directory ops?