perf: reuse HPACK encode buffer across frames

[dorianverlaine]

Motivation

into_encoding allocates a fresh BytesMut for every HEADERS/PUSH_PROMISE
frame, lets it grow through several capacity doublings while HPACK encodes
into it, and then calls .freeze() — which allocates again for the Bytes
refcount header. That is at least two allocations per outbound header block,
on every request and every response.

The block does not need to outlive the call: on the common path it is copied
into the connection write buffer (dst.put_slice) and dropped immediately.
So the buffer can simply be reused across frames on the same connection.

Solution

hpack::Encoder keeps one scratch BytesMut. into_encoding takes it,
clears it, and encodes into it; once EncodingHeaderBlock::encode has
copied the block into the write buffer, it hands the buffer back.

EncodingHeaderBlock::hpack becomes BytesMut instead of Bytes, so the
.freeze() goes away too. The CONTINUATION path keeps its remainder and
does not return the buffer — the next encode just starts from a fresh one —
and splitting that remainder is now split_to on a uniquely-owned
BytesMut rather than a copy.

Nothing else changes: same bytes on the wire, no public API change, both new
methods are pub(crate).

Memory

Worth stating explicitly given #923: this retains one buffer per connection,
sized to the largest header block that connection has encoded, for the
connection's lifetime. For ordinary headers that is well under 1 KiB; a
connection that once sent a header block near max_frame_size will hold
that much until it closes. If that tradeoff is unwanted, the buffer could be
capped or released on idle — happy to add either.

Measurements

cargo bench --bench main on this repo, 5 interleaved rounds per arm
(master vs this branch, rebuilt each round), Apple M-series, Overall in ms,
lower is better:

Benchmark	master	this PR	Δ
current-thread, 100k req	372, 377, 377, 386, 376	383, 369, 369, 367, 372	+1.5 %
multi-thread, 100k req	496, 488, 490, 507, 501	489, 474, 479, 477, 469	+3.8 %
write contention, 1 GiB	270, 284, 286, 275, 278	288, 283, 275, 278, 271	+0.0 %

The multi-thread row separates cleanly — the patched arm is faster in 24 of
25 pairwise comparisons (exact permutation test, two-sided p = 0.016). The
write-contention benchmark is DATA-frame throughput and is unaffected, which
is what you would expect.

It is a small win, and I would not argue it is more than that. It is worth
having mainly because it is on every request in both directions and costs
nothing to keep.

Testing

cargo test --all passes, including the full HPACK fixture suite and
write_continuation_frames / read_continuation_frames /
too_many_continuation_frames_sends_goaway, which cover the split path this
change touches.

[seanmonstar]

Nice! hyper's h1 internals do a similar thing, reusing the header encoding buffer over and over on a single connection. Thanks!