Fix gzhttp transport response.

[DeyiXu]

1. Fix response header Content-Encoding: gzip,zstd but not decompress
2. Server side Content-Encoding is not controlled.
   Fix the decompression problem when Content-Encoding appears gzip and zstd at the same time

[klauspost]

Could you please explain a bit deeper. Perhaps with an example.

Note that we do not decompress if we did not ourselves add the "Accept-Encoding". That is by design.

Without more context I think you are breaking a lot of existing use of this package.

[DeyiXu]

I am implementing a caching middleware, and during use I found that when saving files locally, gzip data that could not be decompressed appeared.

If the data returned through the gzhttp transport middleware needs to be processed and decompressed gzip a second time.

If it can't solve the data perfectly, then what's the point of this middleware's existence?

[DeyiXu]

When accessing an uncertain backend HTTP Server, there is no guarantee that the backend server will fully comply with HTTP standards. There may be some data that does not meet the standards. At this time, the data needs to be processed.

The PR I submitted is to solve this problem.

If there is a problem with my code, please reject my PR and I will continue to improve it.

[klauspost]

There can be plenty of reasons.

A) If "Accept-Encoding" is added upstream, we do not touch the request or the response.
B) If the server returns with "Content-Encoding" without you asking for it, then the server has an issue.

Since you don't really provide any information, I am assuming it is B). I can add an option that will allow for that.

[DeyiXu]

Thanks.

I think the option is feasible.

[DeyiXu]

Looking forward to your code.

[klauspost]

See #978