client reports incorrect error codes when server returns unexpected content-type, content-encoding

[jhump]

These details are not all fully described in the spec (at least not yet). But the conformance suite does have expectations, in an effort to bring consistency to implementations even before the spec updates are complete.

It expects the following:

1. If the content-type has the wrong prefix ("application/" for Connect unary, "application/connect+" for Connect streaming, "application/grpc" for gRPC, and "application/grpc-web" for gRPC-Web), then it appears to be a web server that is not an RPC server. In that case, return an error whose code is derived from the HTTP status code. For gRPC and Connect streaming, where the status code is expected to be 200 OK, this will result in a derived error code of "unknown". This should also be done for any response to a Connect unary response with a non-200 HTTP status whose content-type is not "application/json".
2. If the content-type has a correct prefix, but indicates an unexpected message-codec, the client should report an "internal" error, since the server appears to be an RPC server but sent an invalid response, which is interpreted by the client as an internal server error.
3. If the server sends back a compression encoding that is not supported, the client should report an "internal" error. This is interpreted as an internal server error since a correct server will only use compression that the client is known to accept (via request headers indicating the accepted encodings).
4. If no compression is in use (so no content encoding header or an encoding of "identity"), if a streaming protocol includes the compressed bit set for a message, it should report an "internal" error.

The latter two are consistent with the docs for compression handling with gRPC: https://github.com/grpc/grpc/blob/master/doc/compression.md.

The client implementation in this repo does not behave in the way described above for these scenarios.