Check HTTP response codes, and parse RFC7807 problem reports.

[wiml]

Currently, if something goes wrong and an HTTP request fails or the ACME server rejects a request, the status code will be ignored and the response will be parsed as JSON, BER, or whatever. This patch adds minimal checking for HTTP errors, and in the case of RFC7807-formatted error responses, parses the problem report into a more convenient erlang term representation.

rebar3 ct passes. You can test the error-handling and -parsing functionality by, e.g., removing the rate-limit overrides in boulder's test/rate-limit-policies.yml and rerunning the common tests against that boulder instance.

[gbour]

thanks @wiml. I will have a look this weekend

[gbour]

Hi @wiml. First, thank you for your PR, it is very interesting.

But your changes triggers an exception, when setting an invalid domain name:
current master branch:

> letsencrypt:make_cert(<<"foo">>, #{async => false}).
{error,<<"DNS name does not have enough labels">>}

with your patch:

** Reason for termination = 
** {{badmatch,{problem,{acme,malformed},
                       none,
                       [{status,400},
                        {detail,<<"DNS name does not have enough labels">>},
                        {status,400}]}},
    [{letsencrypt_api,new_authz,6,
                      [{file,"/home/gbour/devel/letsencrypt-erlang-wiml/_build/default/lib/letsencrypt/src/lets
encrypt_api.erl"},
                       {line,83}]},

in fact, it may happen everywhere post() is called and matched with {ok, Nonce, Body}

[wiml]

Ah, I see. In some other code paths the badmatch was at least a better error message than the cryptic error from the ASN.1 parser when trying to parse text as if it were DER, but in that spot it's a step backwards. I'll update this to pass the error along properly in the situations where that's possible.

[wiml]

FWIW, the errored travis-ci check, above (build #215), looks like it was due to a problem with travis, not with this patch specifically.