fix(deps): replace bouncycastle jdk15on with jdk18on 1.85

[orangeCatDeveloper]

What's changed?

Fixes #3540: the project ships BouncyCastle from the abandoned jdk15on line (bcpkix-jdk15on:1.68, 2020) — it no longer receives releases, so its known CVEs will never be patched, and every dependency scan flags it. The maintained jdk18on line shares package and class names, so it is a drop-in replacement; the version is managed once in the root pom:

<bouncycastle.version>1.85</bouncycastle.version>

jdk15on enters the build through two different doors, fixed differently:

1. Direct dependency (hertzbeat-collector-basic)

MqttSslFactory uses BC to parse client certificates/keys for MQTT TLS auth, via a hardcoded bcpkix-jdk15on:1.68 in the module pom. Straight swap to bcpkix-jdk18on:${bouncycastle.version}.

2. Transitive dependency (hertzbeat-collector-nebulagraph)

The vesoft NebulaGraph client brings jdk15on with it — we don't control its pom, so the module now excludes the jdk15on jars from the vesoft dependency and supplies jdk18on explicitly. The vesoft client was compiled against jdk15on, but since both lines expose identical packages/classes it links against jdk18on unchanged — proven by a smoke test that runs its SslUtil on the new jars.

License material

material/licenses is bundled into the binary distribution, so the three manifests and the six per-artifact LICENSE-bc*-*.txt files are renamed/updated to jdk18on/1.85 — otherwise the release would declare components it no longer ships.

Verification

Dependency tree, before → after:

org.bouncycastle:bcpkix-jdk15on:jar:1.68      →   org.bouncycastle:bcpkix-jdk18on:jar:1.85
                                                  \- org.bouncycastle:bcutil-jdk18on:jar:1.85
                                                     \- org.bouncycastle:bcprov-jdk18on:jar:1.85

jdk15on no longer appears anywhere in the reactor, and the docker image lib/ carries only the three jdk18on jars. Every BC consumer was exercised against 1.85, not just compiled:

• MQTT client-cert auth — new MqttSslFactoryTest parses generated PKCS#1 and PKCS#8 private keys through the production getMslSocketFactory path.
• NebulaGraph SSL — new VesoftSslBouncyCastleSmokeTest feeds a BC-generated certificate through the vesoft client's own SslUtil.
• SSH private-key login (mina-sshd uses BC to parse PEM keys) — SshHelper.getConnectSession completed a real handshake (AUTHED) against OpenSSH 9.6.

Full test suites of all modules with BC on the classpath (collector-common, collector-basic, collector-nebulagraph, collector-collector, push) pass.

Checklist

• I have read the Contributing Guide
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

Add or update API

• I have added the necessary e2e tests and all cases have passed.

[Aias00]

Reviewed the full diff (14 files). Clean, well-scoped dependency upgrade — this is exactly how a drop-in crypto bump should be done.

What's good

• Direct swap in collector-basic: bcpkix-jdk15on:1.68 → bcpkix-jdk18on:${bouncycastle.version}, with the version centralized once in the root pom.
• Transitive path in collector-nebulagraph correctly excludes both bcpkix-jdk15on and bcprov-jdk15on from the vesoft client and re-adds bcpkix-jdk18on explicitly; bcprov/bcutil arrive transitively. No missing-class risk at runtime.
• License hygiene: the three manifest files (material/licenses/{root,backend,collector}/LICENSE) and the six per-artifact LICENSE-bc*-jdk15on.txt files are renamed/updated to jdk18on/1.85, so the binary distribution no longer declares components it doesn't ship.
• Verification is strong: MqttSslFactoryTest parses both PKCS#1 and PKCS#8 client keys through the production getMslSocketFactory path; VesontSslBouncyCastleSmokeTest feeds a BC-generated cert through the vesoft client's own SslUtil.

Minor / optional (non-blocking)

• Please confirm mvn dependency:tree shows zero jdk15on artifacts across the whole reactor (including the docker image lib/), since the PR claims this — a CI log snippet would close it.
• Consider promoting the mina-sshd PEM-handshake test into CI (not just local) so the BC-backed key parsing of mina-sshd is guard-railed going forward.
• Tiny nit: the commented-out checker-qual line in material/licenses/backend/LICENSE is untouched — harmless, but you're already in that file.

Approving.