tokio-quiche: size H3 body_recv_buf to readable length

[LynnLi100]

Summary

Follow-up to the lazy body_recv_buf allocation. Previously, once the buffer was first needed it was always allocated at a fixed 64 KiB (BufFactory::MAX_BUF_SIZE), so a connection with a 10-byte body still paid for 64 KiB on its first body read.

This PR sizes the allocation to the amount actually readable on the stream, capped at MAX_BUF_SIZE.

Changes

• Add quiche::Connection::stream_readable_len(stream_id), an O(1) upper bound of unread bytes (recv.max_off() - recv.off_front()), returning 0 when the stream is absent.
• In H3Driver::process_h3_data, size both the lazy allocation and the exhausted-buffer reallocation to body_recv_buf_size(stream_readable_len(stream_id)), which clamps to [1, MAX_BUF_SIZE]. Capacity is kept equal to the limit so the split() invariant (spare capacity == remaining_mut) still holds.

Rationale

stream_readable_len is an upper bound on the buffered body bytes (also counts H3 framing), so we never under-allocate; the cap bounds the worst case exactly as before. Idle/small-body connections now allocate proportionally to their data; large streamed bodies allocate once per driver read-cycle (capped at 64 KiB) instead of reusing a single fixed 64 KiB buffer.

Testing

• Unit test for stream_readable_len.
• Unit tests for the body_recv_buf_size clamp (floor, tracking, cap).
• Driver test asserts the allocated buffer tracks a small body rather than 64 KiB.