fix(deps): backport security fixes to 5.6.x

[vlsi]

Goal

Security patch line for JMeter 5.6.x aimed at users who cannot
immediately upgrade to the upcoming JMeter 6.0. The branch starts from
the rel/v5.6.3 tag and only carries dependency bumps with the smallest
viable version change for each CVE. Hard rules:

• avoid major version bumps where possible,
• minimize minor bumps,
• the build/runtime must keep working on Java 8.

Methodology: CycloneDX SBOM (full transitive resolution) generated from
runtimeClasspath + compileClasspath of every subproject, scanned
with osv-scanner. Results were filtered to the jars actually shipped
in the release distribution (src/dist/src/dist/expected_release_jars.csv).
Test/build-only deps (commons-fileupload, guava, jetty.*,
bcprov/bcpkix-jdk15on, xmlunit-core) are listed by the scanner but are
not part of any release artifact, so they are out of scope.

Fixed CVEs (shipped in expected_release_jars.csv)

Severity	CVSS	Package	From → To	CVE / GHSA
High	7.7	com.thoughtworks.xstream:xstream	1.4.20 → 1.4.21	CVE-2024-47072
Low	2.7	org.mozilla:rhino	1.7.14 → 1.7.14.1	CVE-2025-66453
High	7.5	net.minidev:json-smart (+ accessors-smart)	2.5.0 → 2.5.2	CVE-2024-57699
Medium	5.3	com.jayway.jsonpath:json-path	2.8.0 → 2.9.0	CVE-2023-51074
Medium	6.9	com.fasterxml.jackson.core:jackson-{core,databind,annotations}	2.16.1 → 2.18.6	GHSA-72hv-8253-57qq
Medium	6.9	org.apache.logging.log4j:{log4j-api,log4j-core,log4j-1.2-api,log4j-slf4j-impl}	2.22.1 → 2.25.4	CVE-2025-68161, CVE-2026-34477, CVE-2026-34478, CVE-2026-34479, CVE-2026-34480
High	7.1 / 4.4	org.apache.xmlgraphics:batik-* (18 artifacts)	1.16 → 1.17	CVE-2022-44729, CVE-2022-44730
High	8.9	dnsjava:dnsjava	2.1.9 → 3.6.5	CVE-2024-25638
Critical	10.0 / 9.8	org.apache.tika:tika-parsers	removed from runtime classpath	CVE-2025-54988, GHSA-p72g-pv48-7w9x
Medium	6.5	org.apache.commons:commons-lang3	3.14.0 → 3.18.0	CVE-2025-48924

Notes on the non-trivial bumps:

• jackson 2.16 → 2.18.6 required a one-character test fixture update
  (TestJMESPathAssertion): jackson-core's parser error column index was
  tightened from 3 to 2.
• json-path 2.9.0 pulls slf4j-api 2.x transitively; since
  log4j-slf4j-impl 2.25.x is still built against slf4j 1.x and a
  coordinated slf4j 2.x migration is out of scope for 5.6.x,
  slf4j-api/jcl-over-slf4j are pinned with strictly("1.7.36").
  json-path itself only uses the basic LoggerFactory.getLogger /
  Logger.{info,debug,warn,error} surface, all of which are
  binary-identical between slf4j 1.x and 2.x.
• batik 1.16 → 1.17 is a transitive bump pulled in by lets-plot-batik 4.1.0.
  No batik-bom is published, so each of the 18 batik artifacts is
  explicitly constrained in src/bom-thirdparty/build.gradle.kts.
• dnsjava 2 → 3 is the only available fix (no 2.x patch). The bump
  is source-compatible after replacing Resolver#setTimeout(int, int)
  with the Duration overload and adjusting one test
  (ResolverConfig#servers() now returns List<InetSocketAddress>).
  DnsManagerTest is removed (mirrors master commit c6c6c07e5): the
  test relied on a 2.x quirk and upstream replaced it with a
  MockDnsServer-based suite that is out of scope here.
• tika-parsers is dropped entirely (mirrors master commit 23fa6d530).
  JMeter only used Tika.detect / AutoDetectParser from tika-core;
  the parsers monolith was never wired into the public JMeter API.
  Dropping it eliminates those parser CVEs and reduces the release size.
  tika-core is bumped 1.28.5 → 2.9.4 — see Scanner-flagged but not
  reachable below.
• commons-lang3 3.18.0 deprecated several widely-used helpers
  (ObjectUtils.defaultIfNull, StringUtils.startsWith/endsWith/…,
  RegExUtils.replaceAll, RandomStringUtils.random). Since -Werror
  is on, each call site is annotated with @SuppressWarnings("deprecation")
  at the narrowest scope that still compiles. A follow-up can rewrite
  the call sites to core Java once the dependency is gone (see master's
  b362137 for the pattern).
• A separate build: refresh stale checksum entries for xerces and xml-apis
  commit fixes a pre-existing problem in checksum.xml: the recorded
  SHA-512 for xerces:xercesImpl:2.9.1 no longer matched the artifact
  served by Maven Central, and xml-apis:xml-apis:1.3.04 was missing
  altogether, both blocking any fresh checkout from passing
  verifyReleaseDependencies.

Scanner-flagged but not reachable

tika-core 2.9.4 — CVE-2025-66516 / GHSA-f58c-gq56-vjjf (CVSS 10.0
Critical). Version-based scanners flag this because the upstream fix
ships in tika-core 3.2.2+, and Tika 3.x is compiled for Java 11
(class file major version 55), so it cannot be loaded by a Java 8 JVM.
The Java 8 hard rule for this branch precludes the upstream version
bump.

The vulnerability itself is not reachable in JMeter's runtime
configuration:

• The CVE is an XXE through an XFA form inside a PDF; the only attack
  entry point is org.apache.tika.parser.pdf.PDFParser. In Tika 1.x,
  PDFParser lived in tika-parsers; in Tika 2.x it moved to
  tika-parser-pdf-module.
• JMeter has never shipped tika-parser-pdf-module.
• This PR drops tika-parsers from the runtime classpath (commit
  184d191).
• Inspecting the deployed tika-core-2.9.4.jar confirms it ships only
  the core parsers (AutoDetectParser, CompositeParser,
  CryptoParser, DefaultParser, EmptyParser, ErrorParser,
  NetworkParser, DigestingParser, ParserDecorator,
  ParsingReader). No PDFParser, no XFA, no PDF-related code is in
  the JAR.
• JMeter's actual Tika usage is Tika.detect() (MIME sniffing from
  magic bytes, no XML parsing) in HTTPFileArg and
  ParseCurlCommandAction, plus AutoDetectParser in Document.java,
  which — with no parser modules on the classpath — falls back to
  EmptyParser for unrecognised content.

The XXE-via-XFA attack chain therefore has no entry point in a default
JMeter installation. The CVE remains visible to scanners only because
they compare tika-core version strings, not class presence.

Users who deliberately add tika-parser-pdf-module (or Tika's
tika-parsers-standard-package) to JMeter's lib/ directory bring the
vulnerability back into reach and should either upgrade to JMeter 6.0
(Tika 3.2.3 shipped) or strip PDFParser from their custom Tika
install.

Scope (NOT in this PR)

• jetty 9.4.*, commons-fileupload 1.4, guava 31.1-jre,
  bcprov/bcpkix-jdk15on 1.70, xmlunit-core 2.9.0 — flagged by the
  scanner but only present in test or build configurations; not part
  of expected_release_jars.csv, therefore not shipped to end users.
• Wholesale removal of commons-lang3 (master's b362137) — that change
  spans 200+ files and uses Java 17 syntax; out of scope for a 5.6.x
  patch line.

Verification

Every commit was validated by:

1. ./gradlew -Prelease -PchecksumUpdateAll -PupdateExpectedJars verifyReleaseDependencies
   to refresh checksum.xml and src/dist/src/dist/expected_release_jars.csv.
2. ./gradlew -Prelease --continue build on the JDK 8 toolchain
   (jdkTestVersion=8, JDK 8 was auto-provisioned by
   foojay-resolver-convention). Two network-flaky batch tests
   (batchTEST_HTTPJava, batchHttp4ImplPreemptiveBasicAuth) were
   excluded from the local loop — CI should run the full matrix.