fetch payload of multiple datagrams at once

[kazuho]

Problem: Up until now, the on_send_emit callback has been invoked for each STREAM frame being built. This has become a bottleneck, due to two reasons:

• Applications might have high static cost for generating each payload. For examples, they might be calling pread for each call to on_send_emit.
• Running accounting and prioritization logic for each packet being built is also expensive.

Solution:

Earlier attempts (#609 and #648) tried to reduce the overhead by fetching the payload for multiple QUIC packets in one go—either via preadv, or via pread followed by memmove so the payload ends up exactly where it will be encrypted in place.

The drawback of those approaches is that the payload has to be scattered per packet before encrypted, which is inefficient.

This PR takes a different approach. Assuming the buffer passed to quicly_send has some extra space beyond the region where packets are built, it:

• Switches to out-of-place encryption: frames (including application payload) are written starting roughly one MTU after the packet-build area.
• When quicly_send_stream runs, it reads payload for multiple QUIC packets contiguously into the frame area (i.e., without scattering). It then repeatedly builds a full-sized QUIC packet from the first bytes of the frame data, and prepends a STREAM header to the remaining payload, until the remaining frame data becomes smaller than one MTU.

When running at full speed, quicly_send typically builds multiple packets in batch (often up to ten). Because the packet and frame construction regions overlap within the same buffer, the additional L1$ footprint due to the use of out-of-place encryption is minimized.

Separately, this pull request allows the on_send_emit callback to return length of zero to indicate that payload is not immediately available, which causes quicly_send_stream to bail out with an error code of QUICLY_ERROR_SEND_EMIT_BLOCKED. When using an on_send_emit callback that behaves as such, the stream scheduler should handle the new error code and refrain from calling quicly_send_stream until the payload becomes available.