Payload decompression support for elasticsearch API

[esatterwhite]

Is your feature request related to a problem? Please describe.
In high throughput / high volume deployments, payload ( request + response ) can be rather large, ranging in the MB. This can be expensive on numerous fronts, transfer time, application overhead, server overhead, etc. Elasticsearch supports compression (gzip) of payload, most notably in the /_bulk endpoint for indexing multiple documents. As well as server side compression of api responses.

The latter is less important as clients will just set an http header accept-encoding: gzip,deflate. The server may or may not respect this. The sending of gzippeds payload from the client, however, would need to be supported by quickwit indexers.

Describe the solution you'd like
The quickwit API should honor the content-encoding headers sent by clients allowing for the sending of compressed request bodies. Most importantly GZIP

[guilload]

See also #3990. We want decompression support for both the native Quickwit API and the Elasticsearch API

[fulmicoton]

Tagged as good first issue.

[fulmicoton]

@PSeitz Can we close this?

[PSeitz]

We support now gzip x-gzip and zstd as content-encoding. Let's reopen if we need more formats