Support standard TLS and mTLS in the C++ client

[hongzhi-gao]

Description

Standard TLS and mTLS

Add CA verification and optional PEM client certificate/private key support to the C++ Tree, Table, SessionPool, and C APIs. TLS settings are preserved across reconnects and node discovery. TLCP is intentionally excluded from this PR.

OpenSSL packaging

Build checksum-pinned OpenSSL 3.5.8 from source by default on Linux, macOS, and Windows, and bundle its runtime libraries with the C++ SDK. A compatible system OpenSSL remains opt-in.

Tests

Run the C++ integration tests against real IoTDB servers in plain, TLS, and mTLS modes, including rejection of clients without certificates when client authentication is required.

This is the standard TLS/mTLS part split from #18597; TLCP can be handled independently.

---

This PR has:

• been self-reviewed.
• added documentation for modified behavior.
• added comments explaining non-obvious intent.
• added or updated tests for the changed paths.
• been tested with a real IoTDB server.

---

Key changed/added classes (or packages if there are too many classes) in this PR

• SslConfig
• RpcSslUtils
• SessionBuilder, TableSessionBuilder, and SessionPoolBuilder
• C++ TLS integration-test scripts and fixtures

[HTHou]

Thanks for splitting standard TLS/mTLS support into a separate PR and keeping OpenSSL as the default. I found two issues that I think should be addressed before merging:

1. [P1] Make the macOS OpenSSL libraries relocatable.

   With source builds now enabled by default in FetchOpenSSL.cmake, OpenSSL's Darwin build rules embed an absolute install name under the build directory's _deps/openssl/install/lib/. The packaging code copies the dylibs but does not rewrite their install names or dependent-library references. Setting @loader_path as an RPATH on iotdb_session does not resolve absolute library references. As a result, tests on the build machine can pass while the extracted SDK fails to load on another machine with Library not loaded.

   Could we make these references relative using @rpath/@loader_path, including the dependency from libssl to libcrypto, and test the extracted SDK with the original OpenSSL build/install directory unavailable?

2. [P2] Propagate changes from setSslConfig() to node discovery.

   Session::setSslConfig() only updates impl_->sslConfig_. However, the Session constructor has already created and started a NodesSupplier, which holds its own copy of the previous SSL configuration. With the new C API sequence ts_session_new() -> ts_session_set_ssl_config() -> ts_session_open(), the main connection uses TLS, but background node discovery continues attempting plaintext connections. Discovery therefore fails against a TLS-only server, leaving the endpoint list stale and preventing failover to newly added nodes that were not in the initial list.

   Could we defer starting node discovery until open(), or safely recreate it when the SSL configuration changes? A TLS/mTLS test that verifies endpoint discovery and failover would cover this path; the current single-node SHOW VERSION tests do not.

These findings are based on static review of f90b7228; I have not run a full build or the integration tests locally.