add support for RFC 9297 Capsule Protocol

[marten-seemann]

Fixes #486.

This turned out to be more text than I expected, but it's mostly just copy-pasted from the respective HTTP/3 section.

[Copilot]

Pull Request Overview

This PR adds support for the Capsule Protocol from RFC 9297 by defining a new http namespace for qlog events. The changes extend the existing HTTP/3 qlog event schema to include capsule-related events for logging capsule creation and parsing operations.

• Added a new http namespace with events for capsule protocol operations
• Updated abstract and introduction to reflect expanded scope beyond HTTP/3
• Defined CDDL schemas for capsule events and data types

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Both references point to the same RFC 9297. The second reference should clarify that it's specifically about the Capsule Protocol within RFC 9297, or use a more descriptive reference name like 'CAPSULE-PROTOCOL' to distinguish it from the H3-DATAGRAM reference.

[Copilot]

The comment indicates 'any key-value map' but the CDDL definition restricts keys to text type only. The comment should be updated to reflect this constraint: '; The HTTPCapsule is a key-value map with text keys (e.g., JSON object)'

Suggested change

	; The HTTPCapsule is any key-value map (e.g., JSON object)
	; The HTTPCapsule is a key-value map with text keys (e.g., JSON object)

[LPardue]

We could probably make this part clearer with something like

extensions: Extended CONNECT ({{!EXTENDED-CONNECT=RFC9220}}), PRIORITY_UPDATE ({{Section 7 of !PRIORITIZATION=RFC9218}}), and HTTP/3 Datagrams {{Section 2.1 of !DGRAM-AND-CAPSULE=RFC9297}}). It also defines a schema for the HTTP Capsule Protocol ({{Section 3 of DGRAM-AND-CAPSULE}}.

[LPardue]

The design aspects of this look good to me. We just need to answer the scoping question to see whether it lives in this document or not.

[rmarx]

Looking at the discussion post IETF 124 where we presented the question, the consensus seemed to be "if it's easy and quick to merge, just do it in the current docs" (see https://datatracker.ietf.org/meeting/124/materials/minutes-124-quic-00). This PR was explicitly mentioned as part of the list that should be easy to merge.

As such, @marten-seemann, want to finish this up?