Incorrect typespecs for responses

[Michael Heilmann]

At https://github.com/ex-aws/ex_aws/blob/main/lib/ex_aws/request.ex#L9, the error response is defined simply as

@type error_t :: {:error, {:http_error, http_status, binary}}

However there are code paths (such as https://github.com/ex-aws/ex_aws/blob/main/lib/ex_aws/request.ex#L137) that return non-binary data as the third member of that tuple, such as this abbreviated response I had received:

{
  :error, 
  {
    :http_error,
    <code>,
    %{ body: "<error response body from upstream>", headers: [<header tuples>], status_code: <code> }
  }
}

This makes it difficult to rely on dialyzer with ex_aws as the spec omits valid responses.

Additionally, the success response includes the status_code in actual responses, but the provided type includes the body and headers, but not the status_code:

@type success_content :: %{body: binary, headers: [{binary, binary}]}

Environment

Elixir and Erlang Version

Erlang/OTP 22 [erts-10.7.2.14] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1]

Elixir 1.10.4 (compiled with Erlang/OTP 21)

ExAws version (though by inspection is present on newer versions)

* ex_aws 2.1.9 (Hex package) (mix)
  locked at 2.1.9 (ex_aws) 3e6c7767
* ex_aws_s3 2.1.0 (Hex package) (mix)
  locked at 2.1.0 (ex_aws_s3) 7b6867d3

Hackney version

* hackney 1.15.2 (Hex package) (rebar3)
locked at 1.15.2 (hackney) e0100f8e

Current behavior

Handlers for success and error that include these extra fields are flagged by dialyzer

Expected behavior

The spec includes alternate error shapes, and dialyzer enforces the spec.