Handle byte streams for both success and error responses

[ahl]

When an OpenAPI spec reports that errors may be unstructured, generated clients need a way to express this. Currently they just use () which is obviously imprecise.

There were three options I considered:

1. Add another Error variant alongside ErrorResponse(ResponseValue<E>)--something like UnstructuredErrorResponse(Response)--which would have the raw response
2. Change Error<T> which currently takes any type T to take either a ResponseValue<T> or a Response
3. Add a new type ByteStream to represent the unstructured response body; this could be used within a ResponseValue<ByteStream>

Each of these has its drawbacks. 1 requires clients to consider two--essentially identical--error variants, only one of which would only be relevant for a given API call. 2 imposes the knowledge of the structure of Error types more onerously on mock clients; it requires exposing a trait to treat ResponseValue<T> and Response generically which can also lead to confusing error messages. 3 doesn't give access to rest of the Response structure, extracting only the streaming body via Response::bytes_stream().

After prototyping all three and trying them out with omicron, I chose 3. 1 felt pretty janky with the two nominally conflicting Error variants; 2 felt easy to get wrong and seemed to expose more implementation detail than was desirable; 3 actually had some nice properties of unifying type and status code handling of success and error responses. With 3, we figure out the type of the response T--either a generated type, a ByteStream, or ()--and then the success case is a ResponseValue<T> and the error case is an Error<T>. This has a pleasant symmetry to it.

In Dropshot, the OpenAPI description for an endpoint whose response is completely free-form uses the default response type and the */* content type: there's nothing specific Dropshot can say about the response codes, content type, schema, etc. In those cases, the return value for the corresponding generated client method will be Response<ResponseValue<ByteStream>, Error<ByteStream>> where the only thing distinguishing the success and error cases is the response code that the endpoint applied to its custom response.

For oxidecomputer/dropshot#297, with this PR a method with a streaming response but error types would have a return type that looks like this: Response<ResponseValue<ByteStream>, Error<types::Error>>.

Note that both @leftwo and @iliana have hit conditions applicable to this PR.

[davepacheco]

That sounds like a good approach!

[leftwo]

This (along with latest dropshot) solves the problem I was having!

[leftwo]

These are expected output for test comparison purposes?

[ahl]

Exactly right; this one is used here:
https://github.com/oxidecomputer/progenitor/pull/35/files#diff-086b5af8b29e4521f8cdd3158911231ad150c262d4507f197397e7f6a0bb6a2fR102-R105