bug: Dart HttpClient HTTPS hangs on Linux (BoringSSL client), 30s timeout

Symptom

The Dart end-to-end HTTPS test (server_e2e_test.dart: serves HTTPS with a PEM cert over a real TLS socket) times out after 30 s and returns 503 on ubuntu-latest CI, but passes on macos-latest.

What is and is not affected

• The C++ engine TLS suite (8 tests incl. forced TLS 1.3 keep-alive) uses an OpenSSL client and passes on ubuntu CI. So the engine's TLS I/O works on Linux.
• Only the Dart HttpClient path (BoringSSL client) hangs, and only on Linux. Dart uses BoringSSL on macOS too, where it passes — including against a locally-built OpenSSL 3.0.22 engine (matching ubuntu). So it is not the OpenSSL version and not BoringSSL alone; it is BoringSSL-client + Linux together.

Fixes already tried (did not resolve ubuntu)

• Disabled TLS 1.3 session tickets (SSL_CTX_set_num_tickets(ctx, 0), SSL_OP_NO_TICKET).
• Handle WANT_READ/WANT_WRITE direction changes internally in tlsRead/tlsWrite.
• Set the TLS socket to blocking with SO_RCVTIMEO/SO_SNDTIMEO so OpenSSL resolves direction changes internally.

The 30 s duration matches 6 × the 5 s internal poll in tlsWrite/tlsRead on a persistent WANT_READ-during-write, which is the leading hypothesis but unconfirmed.

Next step

NITRO_TLS_DEBUG=1 tracing is now wired into the engine and enabled on the CI coverage step; the next ubuntu run should log handshake-ok/write-wants-read/etc. to pinpoint the stall. Could not reproduce locally (no Linux environment available), so diagnosis needs the CI trace.

Workaround under consideration until fixed: gate the Dart HTTPS e2e test to macOS (TLS stays covered on Linux by the C++ suite).

Start with the Dart HTTPS case in server_e2e_test.dart and inspect the next ubuntu-latest coverage run with NITRO_TLS_DEBUG=1 enabled. Read the tlsRead/tlsWrite trace for handshake-ok and write-wants-read events to identify the stall. Done means the Dart HTTPS test no longer hangs on Linux while the existing C++ TLS suite remains passing.