ci(perf): HTTPS/TLS performance gates for 3.9

[gg582]

Summary

CWIST 3.9 had zero TLS coverage in perf gates: benchmarks/webserver.json / scripts/ci/benchmark.py gate plaintext HTTP only. This adds a self-contained HTTPS gate suite, closing the loop on #306 (TLS handshake plateau) and locking in the #307 fix (quickack Nagle/delayed-ACK stall).

New files (4, no changes to existing gates):

File	Role
scripts/ci/https_perf_gates.sh	Builds a bench server + gate-1 RTT client (embedded C), generates a self-signed ECDSA cert at runtime, runs the 5 gate workloads, emits one JSON metrics row
scripts/ci/https_gates_eval.py	Evaluates the row: absolute backstop per metric + same-runner-CPU median comparison (imports runner_baseline.py; history in benchmarks/https_gates.json, seeded)
.github/workflows/perf-https-gates.yml	Runs on PRs touching the TLS path, on dev pushes, and on dispatch; updates history only after gates pass on a dev push
benchmarks/https_gates.json	Seeded per-CPU history (Ryzen 5600X row)

Gate table

#	Metric	Workload	Backstop	Healthy (measured)	Pre-#307
1	tls_rtt_p50_ms	Sequential TLS client without TCP_NODELAY, 200 fresh connections, first-response RTT p50 — the #307 regression test	≤ 5 ms	~0.09 ms	~43 ms
2	https_churn_rps	ab -n 6000 -c 32, new connection per request	≥ 1000/s	~1585/s local, 2013 CI	~683/s
3	https_keepalive_rps	wrk -t4 -c100 -d10s	≥ 110k/s	135–179k/s	(unchanged by #307)
4	https_big_gbps	wrk -t4 -c32 -d10s on a 1 MiB body	≥ 2.5 GB/s	~4.0 GB/s	—
5	http_* controls	Same three workloads plaintext	churn ≥ 6k, keep ≥ 150k, big ≥ 5.5 GB/s	13.5–15.8k / 207–274k / 7.8–13.5 GB/s	—

Ratio signal: https_keepalive_ratio (HTTPS/HTTP keep-alive, ~0.65 expected) is recorded but not gated — a large drop hints at TLS-path damage even when absolute gates pass.

Backstop calibration (updated after CI run 37201724744): absolute backstops were initially tuned on a quiet 12-core desktop and proved too tight for shared CI runners (http_big_gbps measured 7.8 vs the 8.0 backstop on a shared EPYC 9V45 while all other gates passed). Commit 94eb670b recalibrated every backstop against the observed CI values with variance headroom; a row rebuilt from that failed run's numbers now passes 7/7, and the pre-#307 row still fails gates 1 and 2.

Runner-relative gating: like the existing runner_baseline.py gates, the absolute backstops are only the any-hardware backstop; once ≥5 history rows exist for a CI CPU model, each metric is also judged against median / allowance (throughput) or median × allowance (RTT), because absolute numbers vary by CI CPU (documented in https_gates_eval.py header).

Local verification (Ryzen 5 5600X, 12 vCPU)

Healthy code (dev + this branch), full end-to-end run of scripts/ci/https_perf_gates.sh + evaluator:

tls_rtt_p50_ms: 0.086   https_churn_rps: 1585   https_keepalive_rps: 179188
http_churn_rps: 13523   http_keepalive_rps: 261719   https_big_gbps: 4.18   http_big_gbps: 13.18
https gates: 7/7 passed  (exit 0)

Negative test (quickack re-arms disabled — simulates pre-#307):

tls_rtt_p50_ms: 43.182  -> FAIL: over the 5.0ms absolute backstop
https_churn_rps: 682.8  -> FAIL: under the 1200.0 absolute backstop
https gates: 5/7 passed  (exit 1)

Gate 1 and gate 2 reproduce the pre-#307 numbers (43ms / 683/s) and fail exactly as designed.

Also verified: make libcwist.a clean, test_https and test_https_park pass on this branch.

Notes

• CI time: one BoringSSL build (~4–5 min) + ~90 s of measurement; comparable to the existing perf-https-handshake-shards.yml workflow.
• The workflow's history-commit step runs only on push to dev after gates pass; PR runs (including forks, which get read-only tokens) never modify the history file.
• Bench server and RTT client are generated into /tmp at runtime; no dependency on example/ certs.

Refs #306, #307