When ClientHello is split into multiple datagrams and arrives at once, don't send a full-sized ACK-only packet in response to the first one

[kazuho]

Recently, clients have started supporting PQ key exchange. ClientHello no longer fits in a single datagram, and the clients are sending two Initial packets at once.

At the moment, quicly sends an immediate ACK while processing the first datagram that creates a connection, even when it has received two datagrams at once (see quicly_accept). This behavior is sub-optimal, as it leads to wasting a full-sized datagram due to it carrying only an ACK.

When accepting a new connection, quicly should process all datagrams available before generating a response. In addition, it might wait for a very small amount of time (e.g., 1ms) to see if more packets are coming.

[kazuho]

#641 is the fix, though I'm not sure if it worthwhile.

The argument for the change is that spending full MTU for an ACK is wasteful prior to address validation, when it is likely that another packet would arrive soon. However, the counterarguments are:

• It is hard to determine the amount of delay that we would want to introduce: the delay should be large enough to cover majority of connections, but small enough so that when packets are actually lost the added delay would not slow down the handshake too much.
• The "waste" is less of a concern when the client is sending 2 packets as its first-flight, because the wasted ratio is 1/6.

Maybe what we should do at first is to quantify the cost of current behavior, by add a metric that counts connections that get blocked by the amplification limit.