Feature request: cover more compression scenarios

[rauanmayemir]

As suggested, filing a separate detailed issue with feature request to add more compression options.
Here are possible scenarios from my experience that come to mind immediately:

1. gRPC client -> Transcoder -> gRPC server handler

This is the most simple case where we set up vanguard transcoder with grpc server behind it and still want to serve non-transcoded grpc requests. In this scenario transcoder should be able to do the following:

1. Recognize that client wants compression, clean up request metadata to let grpc server know it shouldn't apply compression. Or not clean up if backend service compression is enabled via service options)
2. Send request to the grpc handler and after transforming the response, apply compression as requested by client. Or not apply compression if backend returned compressed payload. Or first decompress and the recompress if compression methods are different, e.g client requested gzip, but server is specifically set up to work with zstd
3. Serve compressed response

As a sane default, I'd assume that for a same server grpc handler (i.e not a remote proxy), we want grpc not to apply compression at all and defer everything to transcoder.

2. gRPC-Web/gRPC-REST client -> Transcoder -> gRPC server handler

gRPC-Connect client should be the same. In this scenario transcoder must:

1. Recognize that client wants compression, clean up request metadata to let grpc server know it shouldn't apply compression.
2. Send request to the grpc handler and after transforming the response, apply compression as requested by client.
3. Serve compressed response

This is my personal pain point where gRPC-Web is used in the browser and response compression is essential.
Tricky issue with gRPC-Web is that server may serve the response with chunked transfer encoding, so to apply compression transcoder has to buffer the response, apply compression and then start chunking.