Add nghttp3_conn_read_datagram and nghttp3_conn_write_datagram_prefix

[pimterry]

This provides support for RFC 9297 unreliable HTTP/3 datagrams.

This is something that could be done directly on the QUIC APIs, but there's a few edge cases around validation and it requires reimplementing QUIC varint encoding/decoding, since that's only implemented internally in ngtcp2/nghttp3. Since it's small and integrates neatly here it seems like a good addition from my pov, let me know what you think.

[gemini-code-assist]

Code Review

This pull request introduces support for HTTP/3 Datagrams (RFC 9297) in nghttp3. It adds the nghttp3_recv_datagram callback, updates the callbacks structure to version 4, and implements nghttp3_conn_read_datagram and nghttp3_conn_write_datagram_prefix along with comprehensive unit tests. The review feedback correctly identifies that nghttp3_conn_write_datagram_prefix should check both local and remote settings to ensure HTTP/3 Datagrams are fully negotiated before writing a prefix.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[tatsuhiro-t]

As for uvarint encoding/decoding, I plan to expose those APIs, see #442

[pimterry]

That would definitely help by making it easier to implement this externally.

If that were available, this would still be nice to have I think (makes it easier to implement without understanding the details) but it's not essential. Up to you. This does make it easier for people to do H3 datagrams without needing to understand the framing & validation details, but if encoding is exposed then an external implementation is also not too bad anyway.

[tatsuhiro-t]

With varint encoder and decoder, this is mostly trivial, yes.
That is the one of the reasons that I have not added these functions.
Another reason is that nghttp3 has nothing to do with the content of datagrams. That is entirely for application's interest. Then it is more direct and straight forward to do all processing on application side without interacting nghttp3 with additional callback indirection.

I will split varint encoder/decoder stuff from webtransport branch to another PR, so that I can merge it without waiting for webtransport.

[pimterry]

Ok, great. I'll close this and wait for the encoder/decoder export as an alternative instead, thanks.