[fix][sec][branch-4.x] Upgrade async-http-client to 2.16.1

[lhotari]

Motivation

org.asynchttpclient:async-http-client on branch-4.2 is at 2.15.0. Two releases have shipped since, both entirely security fixes.

2.16.0 fixes GHSA-m452-q8c9-rg2f — a Set-Cookie Domain attribute was not validated against the request host.

2.16.1 fixes 14 further advisories:

Advisory	Summary
GHSA-3wp9-xfwm-rjjf	WebSocket proxy credentials sent to the origin server over a CONNECT tunnel
GHSA-7grg-jcf7-rpmx	Unbounded HTTP/1.1 response decompression enables a decompression-bomb denial of service
GHSA-cf59-3jcr-vfhw	Resumable download index store is created world-readable and follows a planted symlink
GHSA-f8m2-889x-vw4x	Client-wide realm credentials re-sent to a cross-origin redirect target
GHSA-f9m8-cv68-674w	Cookie Domain attribute is not checked against the public suffix list
GHSA-jmqq-x5g9-9p2w	Replay to a different host sends the original host request and credentials to the new host
GHSA-mfj3-87qq-382v	Digest authentication cnonce generated with a non-cryptographic random source
GHSA-qpfv-56x8-xgx4	URL userinfo credentials sent to the HTTP proxy in the request line
GHSA-rqf5-2wxv-rjf4	Digest challenge without a usable nonce downgrades to Basic and sends the password in cleartext
GHSA-rwhr-j9rv-85f8	WebSocket handshake continues after a failed Sec-WebSocket-Accept check
GHSA-v9f2-7rw2-gr2x	Origin credentials sent in cleartext to a proxy that rejects the CONNECT
GHSA-vvp4-63h8-v5pm	Connection pool key omits the authenticated principal, so an NTLM or Negotiate connection is reused across identities
GHSA-x5w6-vm3f-pp6f	SOCKS proxy credentials sent to the origin server over plaintext HTTP
GHSA-xr57-gcx8-52hf	Origin credentials sent to the proxy on the plaintext CONNECT request

Modifications

Bump asynchttpclient.version from 2.15.0 to 2.16.1 and update the matching jar names in the server and shell binary LICENSE.bin.txt files. No other module hard-codes the version; the property is the single source of truth.

The transitive dependency set is unchanged — reactive-streams stays at 1.0.4 and netty-reactive-streams at 2.0.6 — so no LICENSE entries are added or removed. async-http-client 2.16.1 declares Netty 4.1.136.Final, below Pulsar's pinned 4.1.137.Final, and Pulsar excludes io.netty:* and com.typesafe.netty:netty-reactive-streams from the async-http-client dependency in any case.

Behaviour changes upstream documents, and why they do not reach Pulsar

async-http-client documents four behaviour changes in 2.16.1. Three are unreachable from Pulsar:

• Cookie whose Domain names a public suffix is refused — unreachable. Every production AsyncHttpClient construction site calls setCookieStore(null), so no cookie is ever stored or sent.
• A ResponseFilter replaying onto a different host no longer carries the first origin's realm (and the related cross-origin-redirect advisory) — unreachable. Pulsar constructs no async-http-client Realm anywhere; admin authentication is attached as plain HTTP headers. AsyncHttpConnector also disables the library's own redirect follower (setFollowRedirect(false)) and implements redirects itself, and that code is untouched by the bump.
• NTLM and Negotiate connections pooled per principal — no-op, since Pulsar sets no realm. Pulsar likewise uses no async-http-client WebSocket, Digest, SOCKS or resumable-download functionality, so those advisories are unreachable too.

The remaining change does reach Pulsar and is worth calling out: the decompression-bomb fix adds a cumulative 256 MiB ceiling on the inflated size of a single response body. PulsarAdmin defaults acceptGzipCompression to true and the broker gzips its responses, so this ceiling now applies to admin responses. 256 MiB of decompressed JSON is far outside any realistic admin response, and the limit is configurable via the org.asynchttpclient.maxDecompressedResponseSize property, so this is not expected to be observable. Package, function, sink and source downloads do not set the gzip header and are not subject to it.

Verifying this change

• Make sure that the change passes the CI checks.

This change is a dependency upgrade without new test coverage. It was verified locally as follows:

• mvn -Pcore-modules,-main install — BUILD SUCCESS.
• Clean rebuild of the modules that compile against async-http-client (pulsar-client-admin, pulsar-client-tools, pulsar-broker-auth-oidc) — BUILD SUCCESS, confirming real recompilation rather than an incremental no-op.
• mvn dependency:tree confirms async-http-client:2.16.1 and async-http-client-netty-utils:2.16.1 resolve, with reactive-streams:1.0.4 and netty-reactive-streams:2.0.6 unchanged.
• src/check-binary-license.sh passes on both the rebuilt server and shell binary tarballs.
• The shaded client jars were spot-checked because 2.16.1 adds a new classpath resource (public_suffix_list.dat) that is loaded by an absolute path from a static initializer. The shade plugin relocates the resource entry and rewrites the path string constant in lockstep — both land on org/apache/pulsar/shade/org/asynchttpclient/cookie/public_suffix_list.dat — so there is no fail-open in the shaded artifacts.

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment