fix(HttpClient): let local curl set encoding based what it is built with

[joshtrichards]

Summary

This is a mixture of a fix and an enhancement.

In the HTTP client, previously we forced Accept-Encoding to gzip but it's possible for a local curl:

• not to have been built with gzip
• to support additional encoding types

In most cases this won't change behavior (i.e. gzip will still be used). In others, the specific server/client combo will simply choose something "better".

Notes:

• GuzzleHttp online docs are out of date:
  • [7.9] Improve Accept-Encoding documentation guzzle/guzzle#3215
  • https://github.com/guzzle/guzzle/blob/7b2f29fe81dc4da0ca0ea7d42107a0845946ea77/docs/request-options.rst#decode_content
• https://php.watch/articles/curl-php-accept-encoding-compression
• CURLOPT_ACCEPT_ENCODING is the non-deprecated equivalent of CURLOPT_ENCODING
  • https://www.php.net/manual/en/curl.constants.php#constant.curlopt-accept-encoding
  • https://curl.se/libcurl/c/CURLOPT_ACCEPT_ENCODING.html

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[ernolf]

Setting

$options['curl'][CURLOPT_ACCEPT_ENCODING] = '';

tells libcurl to advertise all encodings it was built with (e.g. br, zstd, gzip, deflate).
However Guzzle’s response decoding is done in PHP, not by libcurl.

Guzzle only transparently decodes:

• gzip
• deflate
• br only if ext-brotli (brotli_uncompress()) is available

So this configuration can cause a real protocol mismatch:

1. libcurl advertises br
2. the server selects Content-Encoding: br
3. PHP/Guzzle cannot decode it
4. the client receives still-compressed bytes and treats them as plain text

That leads to:

• corrupted responses
• JSON decode failures
• empty or garbage payloads
• subtle data corruption with no explicit error

This is not theoretical — most PHP builds ship without ext-brotli, while libcurl in modern distros often supports Brotli and Zstd.

PR #55433 solves this correctly by advertising br only when PHP can actually decode it (function_exists('brotli_uncompress')), otherwise falling back to gzip, with full test coverage.

That keeps HTTP/2 + modern compression while guaranteeing that every negotiated encoding is safely decodable by Guzzle.