Fix C client SSL test hang on long-hostname runners (cap cert CN at 64 chars)

Root cause (confirmed via gdb thread dump on a long-FQDN Linux runner):

gencerts.sh derives the X.509 CommonName from `hostname -f`. On hosts with a
long FQDN -- e.g. Kubernetes pods / self-hosted CI runners whose names look like
rdev-aks-...-cq4mx.corp.rdev.svc.cluster.local (~80 chars) -- the CN exceeds the
64-character ASN.1 limit, so every `openssl req` fails with
"string too long:maxsize=64" and NO certificates are produced. The Java test
server then silently skips its secure port (22281 never listens), and
Zookeeper_simpleSystem::testSSL (TestClient.cc) issues a synchronous zoo_create
against 127.0.0.1:22281 whose session can never establish. Synchronous ops on
such a handle have no per-call timeout, so the IO thread spins on connect-refused
and the main thread blocks forever in wait_sync_completion -- hanging the entire
full-build-java-tests / full-build-cppunit-tests cppunit run.

This is why the hang only reproduced on long-FQDN runners and not on upstream CI
(short hostnames), and why it had nothing to do with the C client itself.

Fix: truncate the CN-deriving FQDN to 64 characters in gencerts.sh.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: arkmish

zookeeper-client/zookeeper-client-c/ssl/gencerts.sh

@@ -34,6 +34,13 @@ FQDN=`hostname -f`
 FQDN=${1:-$FQDN}
 FQDN=${FQDN:-"zookeeper.apache.org"}
 
+# An X.509 CommonName is limited to 64 characters (ASN.1 upper bound). Hosts with
+# long fully-qualified names -- e.g. Kubernetes pods or CI runners -- otherwise make
+# `openssl req` fail with "string too long:maxsize=64", which leaves no certificates
+# generated, so the test server never opens its secure port and the SSL client tests
+# hang. Truncate the CN to stay within the limit.
+FQDN=${FQDN:0:64}
+
 # Generate the root key
 openssl genrsa -out rootkey.pem 2048