[EXPORTER] optimize OTLP HTTP compression

[marcalff]

Investigate and/or implement possible performance improvements.

Related to this idea from #2530

Do you think we can use the in-place compression of the data without using a separate output buffer compressed_body, as suggested here - https://stackoverflow.com/questions/12398377/is-it-possible-to-have-zlib-read-from-and-write-to-the-same-memory-buffer/12412863#12412863. This is suggested by "Mark Adler", the author of zlib, and would be better memory optimzation in the hot-path of upload.

[github-actions]

This issue is available for anyone to work on. Make sure to reference this issue in your pull request.
✨ Thank you for your contribution! ✨

[perhapsmaple]

Hi, I looked at implementing in-place zlib compression suggested by @lalitb. A couple of issues that I need some help with:

1. For the case where the data is insufficiently compressible, the function allocates a temporary buffer, copies the remaining uncompressed data into it, and then completes the compression from the temporary buffer into the remaining space in the output buffer. To avoid this scenario, the author recommends to set max to be equal to deflateBound(stream, len). If we follow the same advice, then do we resize http_requrest->body before every compression, or do we resize only when the function fails with Z_BUF_ERROR and then resize the buffer and retry compression?

2. The deflate stream can be reused across multiple calls, but is not thread safe. From what I can see, the Session::SendRequest method seems to be used in a thread-safe way in the OtlpHttp exporter. If so, we can initialize the stream object once per session and reuse it for multiple requests.