fix(ext/node): do not resume client TLS sessions unless requested - #36592

This re-applies the session without the syntheticSessionMatches gate. setSession() stores this._session even when validation fails, so after an autoSelectFamily handle swap a session that failed the host:port check still flips allow_resumption on. Mirror setSession():

if (this._session && this._sessionReused) {
  this._handle.setSession(this._session);
}

nit: options here is _tlsOptions, which has no host/port, so the computed key is "<servername>:" and never matches a synthetic session (they always embed the port). Effectively dead code. Harmless for tls.connect(), which re-applies the session against kConnectOptions later, but worth pointing at the right options object or dropping the branch with a comment.

P2: Revalidate sessions when reinitializing the handle

When autoSelectFamily falls back to another address after an invalid or host/port-mismatched session was supplied, setSession() retains that buffer in this._session but marks _sessionReused false. This path passes the nonempty buffer directly to the new native handle, enabling the shared cache and allowing an unrelated cached session to be resumed despite the earlier validation failure. Please only reapply the session when _sessionReused is true.

This is a second, distinct fix bundled into the PR (commit e5ba4bf) and it isn't mentioned in the description. I traced it and I agree it's correct — op_set_default_ca_certificates clears both cached_default_verifier and cached_insecure_verifier on every change (ext/node/ops/tls.rs:236-238), so the verifier Arc identity that rustls keys compatible_config on stays consistent, and without this change opt-in resumption would silently never work after tls.setDefaultCACertificates().

Two asks:

1. Please describe it in the PR body — it's a behavior change reviewers shouldn't have to reverse-engineer from the diff.
2. It has no test. Please add one: setDefaultCACertificates(), then two tls.connect()s where the second passes options.session, and assert isSessionReused() === true. That's exactly the regression this line guards.

nit: inferring intent from !session.is_empty(), with JS passing new Uint8Array(0) to mean "disable", is indirect. A dedicated set_session_allowed(bool) fast op would say what it means and drop the sentinel buffer on the JS side. Cosmetic — not blocking.

Worth spelling out the user-visible consequence here: Node's _init does if (options.session) ssl.setSession(options.session), so after this change new tls.TLSSocket(sock, { session }) constructed directly (not through tls.connect()) will never resume — kConnectOptions is never set, so syntheticSessionMatches() always returns false.

I think that's an acceptable trade given the synthetic-session design, but the comment should state it so the next person doesn't treat it as a bug.

Related: session: options.session in the options object passed to new TLSSocket() in tls.connect() (~line 1699) is now dead. Drop it or annotate it.

The gating logic itself is right. One ordering note that isn't in the diff but is load-bearing for it: in tls.connect() (~line 1726) tlssock.setSession(options.session) runs after tlssock.connect(options, tlssock._start). It works today only because connect() defers _start to the 'connect' event, and rustls reads the store lazily in ClientConnection::new inside start() (tls_wrap.rs:2420).

tlssock[kConnectOptions] = options is already assigned above the connect() call, so moving the if (options.session) block up above tlssock.connect(...) removes the hazard for free. Cheap robustness win.

This re-apply path (Happy Eyeballs / autoSelectFamily fallback re-creating the TLSWrap) is new code with no test coverage. Please add one — connect with autoSelectFamily: true to a host where the first address fails, pass options.session, and assert resumption still happens on the fallback handle.

Good that the actual regression (connection 2 must not resume) is covered.

Connection 5 only feeds garbage bytes, which any check would reject. The property setSession()'s comment actually claims is stronger: a well-formed synthetic session issued for a different host:port must not enable resumption. Please add that case — take the session from a connection to server A and pass it to a connection to server B, assert isSessionReused() === false. That's the one that would catch a regression in syntheticSessionMatches().

nit: this is one ~130-line test covering five distinct scenarios. Splitting it with t.step() per connection would make a failure point at the case that broke instead of a bare assertEquals(false, true).