[confighttp] Support snappy and zstd compression on the server side

[swiatekm]

We should support the same compression methods on the client and server sides of confighttp. Right now we have:

• Client side: gzip, zlib, deflate, zstd, snappy
• Server side: gzip, zlib, deflate

If there isn't a good reason we don't support zstd and snappy on the server side, then I can work on adding them.

[atoulme]

Please take a look at #7636

[tigrannajaryan]

Ideally we also want a compression method negotiation added to OTLP spec so that we can have an "auto" setting.

[atoulme]

How would that work? Would you use a similar mechanism as Accept-Encoding? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding

[tigrannajaryan]

How would that work? Would you use a similar mechanism as Accept-Encoding? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding

Yes, with 2-step negotiation for the server's accepting side. The initial client request should be in old encoding until it gets a response from the server about acceptance of the new encoding. Client should also be ready to go back (can happen in load-balanced deployments, mid new version rollout).

[atoulme]

That sounds like it warrants its own issue. I will create one and link it here.

[swiatekm]

zstd was added in #7927, but snappy is still missing.

[JustinMason]

Seeking authorization to commit for the linux foundation, but in the meantime this WIP handles the snappy compression, supporting a Prometheus remote write endpoint using the confighttp core lib.
#8983

[swiatekm]

Looks like this can be closed with #8983.