quic: guard against null impl_ in UpdateDataStats

[zerone0x]

When a QUIC session's handshake fails or the connection is
terminated early, `UpdateDataStats()` can be called before `impl_`
has been initialized, leading to a null pointer dereference
and SIGSEGV.

Add an early return when `impl_` is nullptr to prevent the crash.

Fixes: #62057

[addaleax]

Can you add a regression test?

[zerone0x]

added a regression test in test/parallel/test-quic-session-update-data-stats-after-close.mjs — creates a session with datagrams enabled, sends a datagram and immediately closes on both sides to race the on_exit UpdateDataStats() call against the destroy, which is the path that was crashing before the fix

[Renegade334]

This doesn't crash on main for me, it just gets killed for a non-settling promise. With NODE_DEBUG=quic:

QUIC 662671: endpoint created
QUIC 662671: endpoint listening as a server
QUIC 662671: endpoint created
QUIC 662671: endpoint connecting as a client
QUIC 662671: session created
QUIC 662671: new server session callback QuicEndpoint { ... } Session { ... }
QUIC 662671: session created
QUIC 662671: session handshake callback localhost h3 TLS_AES_128_GCM_SHA256 TLSv1.3 unable to get local issuer certificate UNABLE_TO_GET_ISSUER_CERT_LOCALLY
QUIC 662671: gracefully closing the session
Warning: Detected unsettled top-level await at file:///tmp/node/test/parallel/test-quic-session-update-data-stats-after-close.mjs:52
await clientSession.closed;
^

[zerone0x]

good catch on both — fixed in the latest commit:

• added ca: certs to the client connect() call so TLS validation passes against the self-signed agent1-cert.pem. without it the client rejects the server cert, the session never opens cleanly, and await clientSession.closed hangs
• track serverSession.closed separately so the test waits for both sides to tear down before exiting

on the crash reproduction point: you are right that this does not trigger the actual crash path. the packet-allocation failure inside SendDatagram that originally caused the null deref cannot be induced from the JS side (the JS sendDatagram() has a #isClosedOrClosing guard that prevents reaching the C++ path once close is called). the test exercises the closest reachable scenario — datagrams fired immediately before close() on both sides — and validates that the if (!impl_) return guard does not regress. the comment in the test now explains this limitation explicitly.

if a cctest that exercises UpdateDataStats() directly after Destroy() would be preferred over the JS-level test, happy to add one instead.