Enable grpc compression for infinite tracing

[nrcventura]

Thank you for submitting a pull request. Please review our contributing guidelines and code of conduct.

Description

Enables gzip compression by default to reduce the amount of bytes in transit, and adds a configuration setting to turn off the compression.

Author Checklist

• Unit tests, Integration tests, and Unbounded tests completed
• [ ] Performance testing completed with satisfactory results (if required) There is a separate issue covering performance testing
• Agent Changelog or Lambda Agent changelog updated

Reviewer Checklist

• Perform code review
• Pull request was adequately tested (new/existing tests, performance tests)
• Review Changelog

[JcolemanNR]

Nice! I think this still needs the supportability metric for compression enabled/disabled, and possibly some integration test coverage for Infinite tracing when compression is disabled. I'm not sure how to do it, but it would be nice if the integration tests verified that the grpc streams were actually compressed/uncompressed when the grpc-internal-encoding-request header is set. My thinking is that our current tests would not catch it if we upgraded to a version of Grpc.Net that did not support the grpc-internal-encoding-request header. Not sure if that's something we are concerned about.

[nrcventura]

Nice! I think this still needs the supportability metric for compression enabled/disabled, and possibly some integration test coverage for Infinite tracing when compression is disabled. I'm not sure how to do it, but it would be nice if the integration tests verified that the grpc streams were actually compressed/uncompressed when the grpc-internal-encoding-request header is set. My thinking is that our current tests would not catch it if we upgraded to a version of Grpc.Net that did not support the grpc-internal-encoding-request header. Not sure if that's something we are concerned about.

• I plan on submitting a follow up PR that adds the supportability metric.
• I did not see any added value in having an integration test that covers the compression logic, because I did not find a reasonable method to detect whether or not compression was used. On the client side, compression is meant to be transparent. In theory you can enable and sniff the grpc logs, but those logs are very verbose and difficult to enable and capture within the agent. If we stood up a mock trace observer, we can either look at raw http headers (which are only visible in the aspnetcore grpc dotnet implementation) or via the grpc logs. I was unable to get grpc core to connect to a mock trace observer that leverages aspnetcore and grpc dotnet. The grpc logs were also very verbose. So given those complexities, I think that it is better to just acknowledge the potential risk (that compression may not work) than to significantly increase the complexity of the infinite tracing tests.

These metadata headers that begin with grpc are treated as special headers by grpc libraries. They are meant to control grpc behavior on a per-call basis. As such, some of those headers are not included in the raw http communication. The few that are included in the raw http communication are meant to control grpc library behavior on the server, and are actually removed from the header collection on the server. The header that we're leveraging is one of the special headers that does not get sent with the http communication. grpc-encoding is the header that is ultimately sent with the http communication, so that the grpc library on the server knows that it needs to decode the bytes using the appropriate decoder before deserializing the protobuf payload. grpc-encoding is not visible in the header collection by the time the data is sent to the code we have control over.