Reevaluate the compression handling of the REST Client

[geoand]

Description

The REST Client currently introduces ClientGZIPDecodingInterceptor as way to handle gzip encoded input.

This is not ideal for a couple reasons:

• Vert.x should already handle this
• It doesn't support other values of the Content-Encoding header

Moreover the name of the property (enable-compression) is just plain wrong as it should be enable-decompression

Implementation ideas

No response

[quarkus-bot]

/cc @cescoffier (rest-client)

[geoand]

@cescoffier I am taking a deep look at the compression stuff and I see you have added this.

What happens is that when quarkus.http.enable-compression is set to true,
then HttpHeaders.CONTENT_ENCODING will be set to HttpHeaders.IDENTITY which disables all compression.
This to me seems the opposite of the intention.

Am I reading this completely wrong, am I missing something else or is there an actual bug here?

[geoand]

In any case #46499 is the proper fix.

Two things to note about that fix:

• It took me forever to create a proper test that actually verifies what we think it should verify
• As I mentioned in the description, the enable-compression property of the REST Client is misleading, but I don't really want to change it currently...