quic: add support for custom app ticket data config & 0RTT validation

[pimterry]

(Extracted from #63995)

When sending data, for any protocol with configuration parameters, you'll need to know the parameters the server is using. With early data that's difficult because in a 0RTT world you have no live information from the server to use at the point when you build your early data message.

To solve this, QUIC servers can include custom app protocol configuration in the session ticket. The client just sends early data with the last config they saw, but also send those configuration params back to the server in the ticket when resuming the session. The server can check that data, and if the current configuration isn't compatible, it can reject the early data completely (so the client falls back to 1RTT, instead of resuming using data linked to now-incompatible params).

This works well perfectly existing HTTP/3 setup (which sets the current SETTINGS in the ticket, and validates any received tickets for resumption match or are stricter than the current value). For other QUIC protocols though currently there is just a default case that returns empty data when creating tickets, and always returns true when validating them - accepting all configurations blindly. This would make it difficult to deploy 0RTT with many QUIC protocols in the real world, or to get anywhere near the existing HTTP/3 behaviour with a custom JS implementation.

This PR adds a appTicketData option as a simple solution: you can configure the server with a fixed value (some serialized version of your protocol configuration) and it will be added to all tickets. All received tickets will be validated against the fixed value, checking for an exact match. If you change your server configuration, tickets will stop matching, and you won't get invalid early data. This also drops the return true fallback to return false to fail-closed (1RTT) by default if there's no ticket configuration provided (debatable, but seems safer imo).

This first pass is fairly simple, but should be sufficient for most single-protocol servers imo. In future we could expand the option to also accept a callback, where you can use the received ALPN + SNI to generate the appropriate a per-protocol/sni value, and a validation callback for custom validation (e.g. implementing the HTTP/3 validation in JS) but I think we can punt that to later on, and extend this API in that direction only if required.

(Honestly the HTTP/3 split PR doesn't really need to include this one - but it fitted into the "what primitives would you need to be able to implement HTTP/3 in JS on top of our QUIC API". We could punt it entirely, and just drop 0RTT in that case instead if we're not sure how this should work yet).

[nodejs-github-bot]

Review requested:

• @nodejs/quic