Don't decompress agent data

[felixbarny]

When agents send compressed data, the extension should not decompress it, just to compress it again when sending the data to APM Server.

Buffering compressed data is also lighter on memory.

The extension needs to remember the Content-Encoding header the agent has sent and use the same when forwarding the data to APM Server.

See also elastic/apm#518 (comment)

[felixbarny]

There's a related question whether the extension should compress the data from agents that send uncompressed data while reading from the stream. Benefits are that the extension has to buffer less in memory. However, agents may need to wait longer for the extension to respond. Therefore, it doesn't seem worth it for now.

[felixbarny]

I've gone back-and-forth a bit whether agents should send compressed or uncompressed data to the extension. Based on discussion on benchmark results elastic/apm#518 (comment), I think agents should send uncompressed data for now. This makes implementing this task less urgent.

In the future, agents may always send data with lz4 compression. It would be unfortunate if the extension decompresses that as it can slow down the response to the agents, which is on the critical path. Also, it would increase the amount of data the extension needs to buffer in memory.

[felixbarny]

The extension needs to ensure that it always sends out compressed data, even if agents send uncompressed data. As mentioned in #71 (comment), the extension should not compress incoming data, only outgoing data to minimize user-perceived latency.