Fix TLS connection mismatch in PVAClient tcp_handlers map

[george-mcintyre]

Problem

PVAClient.tcp_handlers is a ConcurrentHashMap keyed by InetSocketAddress alone. When a plain-TCP search response arrives for the same address:port before the TLS response, computeIfAbsent returns the stale plain-TCP handler and the connection is permanently stuck on plain TCP for that address — even after the TLS search response arrives.

Root Cause

The map key does not encode the TLS flag, so a plain-TCP entry silently shadows any later request to open a TLS connection to the same socket address.

Fix

• Add a tls_disabled flag to PVAClient (default false).
• When tls_disabled=true, force use_tls=false in the computeIfAbsent lambda so the map is always populated with a plain-TCP handler, regardless of what the search response advertises.
• Thread tls_disabled through to ChannelSearch so search requests never advertise TLS support when disabled, preventing servers from ever replying with a TLS flag.
• Add a PVAClient(boolean tls_disabled) constructor for callers that need a plain-TCP client (e.g., the CertificateStatusMonitor, which must avoid infinite recursion).

Files Changed

• core/pva/src/main/java/org/epics/pva/client/PVAClient.java
• core/pva/src/main/java/org/epics/pva/client/ChannelSearch.java

[sonarqubecloud]

Quality Gate failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE