[REQ] [Java] Option to omit the trust-all-certificates hook from the generated ApiClient (jersey2/jersey3/okhttp-gson)

[K3vChan]

Is your feature request related to a problem? Please describe.

The generated Java ApiClient for the jersey2, jersey3 and okhttp-gson
libraries always contains disableCertificateValidation(...), which builds an
X509TrustManager with empty checkClientTrusted/checkServerTrusted bodies
and a getAcceptedIssuers() returning null, then installs it into the
SSLContext.

Static analysis flags this. CodeQL reports java/insecure-trustmanager
("TrustManager that accepts all certificates") at high severity, and on
GitHub that fails the code scanning check on any PR that adds or touches the
generated client. Sonar's java:S4830 covers the same pattern.

The method is a protected opt-in hook — nothing in the generated client calls
it, and the javadoc on customizeClientBuilder tells you to override and invoke
it if you want it. But analysers flag the code as written, not as reached, so
projects that commit their generated client (or scan target/) carry a
high-severity alert for a method they never use.

There is currently no way to opt out:

• No configOption gates it. The block is unconditional template text — the
  only mustache conditionals near it are authMethods, jsr310, useJackson3,
  servers and operations.
• Inline suppression comments are not viable: the file is regenerated, so any
  hand edit is lost (and is caught by CI if the project verifies that its
  committed generated code matches the spec).
• .openapi-generator-ignore excludes whole files, and ApiClient is the class
  you configure, so it cannot be skipped.

Notably this is not consistent across the Java libraries. Of the six that ship
an ApiClient.mustache:

library	emits the trust-all block
jersey2	yes
jersey3	yes
okhttp-gson	yes
native	no
apache-httpclient	no
resttemplate	no

Half of them do fine without it, which suggests it is incidental rather than a
deliberate cross-cutting design.

Describe the solution you'd like

A configOption on JavaClientCodegen gating the hook, following the existing
pattern of options like useSingleRequestParameter. Something like:

<configOptions>
  <generateInsecureTlsHook>false</generateInsecureTlsHook>
</configOptions>

Defaulting to true, so current output is unchanged and the change is not
breaking — anyone who overrides customizeClientBuilder and calls the hook
keeps compiling. Setting it to false would omit the method and the imports
that become unused with it (SSLContext, TrustManager, X509TrustManager,
X509Certificate, SecureRandom, KeyManagementException,
NoSuchAlgorithmException).

The change would wrap the block in the three affected templates under
modules/openapi-generator/src/main/resources/Java/libraries/{jersey2,jersey3,okhttp-gson}/ApiClient.mustache.

I verified locally that removing the method and those seven imports from the
jersey3 template produces the same file count and compiles clean, so nothing
else in the generated client depends on it.

Describe alternatives you've considered

• <templateDirectory> override of just ApiClient.mustache. This works —
  the generator falls back to embedded templates for files you do not supply —
  but it means vendoring a ~1550-line template pinned to one generator version.
  On the next version bump ApiClient silently stays on the old template while
  every other generated file moves forward, with no warning. That failure mode
  is worse than the alert.
• JAVA_POST_PROCESS_FILE to strip the method. An invisible text transform
  over generated code; hard to review and easy to break.
• Dismissing the alert in the scanning tool. Works, but it has to be redone
  per repository, and it suppresses a real "trusts any certificate" finding
  rather than removing the code, so a future genuine occurrence in the same file
  is easier to miss.

Additional context

Reproduced with openapi-generator-maven-plugin 7.25.0, generatorName=java,
library=jersey3, on JDK 21.

Happy to submit the PR (templates, a codegen test, and regenerated samples) if
maintainers agree on the option name and on defaulting it to true.

[K3vChan]

Correction on scope, having now looked at okhttp-gson properly: it should be excluded.

The trust-all X509TrustManager is present there, but it sits inside applySslSettings() behind the runtime verifyingSsl field, which has a public setVerifyingSsl(boolean) setter and defaults to true. That makes it a live, documented feature rather than the dead protected hook that jersey2/jersey3 have. Gating it would break existing callers, so it should stay as is.

Opened #24786 covering jersey2 and jersey3 only, defaulting to true so no generated output changes. Regenerating every java* sample produces no diff.