Compression handling has some issues

[jhump]

According to the gRPC docs for compression, when a client or server sends a “grpc-encoding” header with an unrecognized/unsupported encoding the recipient MUST report that as an error. A client receiving an unsupported encoding from a server should report an internal error code.(See bullet 5 in the test cases section of that doc.) A server receiving an unsupported encoding from a client should report an unimplemented error code. (See bullet 4 in the test cases section of that doc.)

Similarly, when a message is sent where the envelope has the “compressed” bit set, but there is no encoding for the stream (or the encoding is “identity”), the recipient MUST fail with an internal error code.

The client in this package returns an unknown status (with an empty error message) in both of these situations instead of internal.

The server in this package does not necessarily produce any error for either of these:

• When the server receives an unsupported encoding, it does nothing and will succeed if there are no actual messages in the stream with the compressed bit set.
• When the server receives an unsupported encoding and encounters a compressed message, it closes the connection. Clients observe an unavailable error due to the loss of network connection.
• When a server receives a message with the compressed bit set, but no compression (encoding header is absent or set to “identity”), the server ignores the flag. If the compressed payload can successfully be parsed as a Protobuf, the RPC can succeed (though the message is surely invalid).