Sending datagrams is asynchronous.

We are maintaining a quic implementation, and we implemented h3. But when we updated h3-datagram to 0.0.2, we found that we could not implement SendDatagram. Because the process of initializing the packet sender and sending the datagram is asynchronous, but the interface provided by h3-datagram is completely synchronous.

For example, in order to get SendDatagramErrorIncoming::NotAvailable/TooLarge, we must already know the peer's transport parameters. However, the handshake process is asynchronous rather than synchronous. Requiring implementors to already be on a handshake-completed connection would place a huge burden on quic implementors.

In addition, a quic implementation may only buffer datagrams to a limited extent, so sending datagrams will hang while waiting for buffering, and the waiting process is also asynchronous.

Start with the SendDatagram interface and SendDatagramErrorIncoming variants described in the issue, then inspect how h3-datagram 0.0.2 models handshake state and packet sending. The work is complete when the interface can represent asynchronous initialization, error availability, and buffering without requiring a completed handshake.