[improve][misc] Upgrade Conscrypt to 2.6.2 to restore the native library glibc baseline

[lhotari]

Follow-up to #26314.

Motivation

#26314 upgraded Conscrypt 2.5.2 → 2.6.1 to pick up the linux-aarch_64 native binary. That
release, however, silently raised the glibc floor of all the bundled JNI libraries, because
upstream built them on newer GitHub runners. Checking the ELF version requirements of the shipped
.so files (objdump -T lib*.so | rg -o 'GLIBC_[0-9.]+' | sort -uV):

Conscrypt	linux-x86_64	linux-aarch_64
2.5.2 (previous baseline)	GLIBC_2.16	not shipped
2.6.1 (current master)	GLIBC_2.35	GLIBC_2.34
2.6.2 (this PR)	GLIBC_2.14	GLIBC_2.17

2.6.1 pulls in _dl_find_object@GLIBC_2.35 plus the post-libpthread-merge
pthread_*/dlopen/dlsym@GLIBC_2.34, so System.loadLibrary for the Conscrypt JNI library
fails on a number of platforms that 2.5.2 supported:

• RHEL 9 / Rocky 9 / Alma 9 and Amazon Linux 2023 — glibc 2.34, so the 2.35 symbol is missing
• Ubuntu 20.04 LTS and Debian 11 — glibc 2.31
• Amazon Linux 2 — glibc 2.26

Conscrypt is the recommended TLS provider on the web-service path (webServiceTlsProvider=Conscrypt
is the default in conf/broker.conf, conf/proxy.conf, conf/standalone.conf and
conf/functions_worker.yml), so a failing native load degrades TLS on those platforms.

Since #26314 has not been part of any release yet, this regression has not reached users — but it
would ship with 5.0.0-M1 if left as is.

Conscrypt 2.6.2 rebuilds the natives in an
Ubuntu 20.04 container (google/conscrypt#1527),
restoring the low floor while keeping all five native binaries — including the linux-aarch_64 one
that motivated #26314.

2.6.2 additionally makes BufferAllocator.allocateHeapBuffer non-abstract again
(google/conscrypt#1526). 2.6.0 had made it
abstract, which orphaned external subclasses compiled against older Conscrypt — notably Netty's
ConscryptAlpnSslEngine.BufferAllocatorAdapter, which only overrides allocateDirectBuffer. For
Pulsar this was latent rather than an active break: I verified that such a subclass still loads,
instantiates and serves allocateDirectBuffer on 2.6.1 (AbstractMethodError only fires on
invocation), that nothing inside conscrypt-openjdk-uber ever calls allocateHeapBuffer, and that
Pulsar passes ApplicationProtocolConfig.DISABLED in TlsContexts so it never constructs that Netty
engine on its own path. It is still worth taking the fix, since gRPC/Netty stacks bundled elsewhere
in the distribution can construct it.

Modifications

Bump conscrypt in the version catalog from 2.6.1 to 2.6.2 and update the jar filename in the
server and shell binary LICENSE.bin.txt files. No code changes.

The complete Java API delta between 2.6.1 and 2.6.2 is a single line — allocateHeapBuffer going
from abstract to concrete — and the jar entry lists are otherwise identical, so this is a
drop-in patch upgrade.

I also confirmed that 2.6.2 retains the
google/conscrypt#1060 fix for
issue 1015, which #26314 depends on when it
removed the processConscryptTrustManager workaround: TrustManagerImpl.getHttpsVerifier() still
falls back instance verifier → static default → Platform.getDefaultHostnameVerifier().

Verifying this change

• Make sure that the change passes the CI checks.

This change is a trivial rework / code cleanup without any test coverage.

Beyond CI, this was verified locally as follows:

• ./gradlew checkBinaryLicense passes for both the server and shell distributions, and both
  tarballs ship conscrypt-openjdk-uber-2.6.2.jar. (jetty-alpn-conscrypt-server drags Conscrypt
  2.6.0 in transitively; the catalog-driven platform forces it up to 2.6.2.)
• ./gradlew quickCheck and ./gradlew spotlessCheck checkstyleMain checkstyleTest pass.
• JdkSslContextsTest, TlsFactorySupportTest and DefaultBrokerTlsPolicyTest pass. Note that no
  test in the repository actually installs the real Conscrypt provider, so I additionally ran a
  standalone check against the 2.6.2 jar confirming that the native library loads, that a TLSv1.3
  handshake plus data round-trip succeeds through the Conscrypt JSSE provider, and that a
  TrustManager from the standard TrustManagerFactory still resolves the default hostname
  verifier without the removed workaround.

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

Conscrypt org.conscrypt:conscrypt-openjdk-uber is upgraded from 2.6.1 to 2.6.2 (patch release).

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete