core: allow a session to widen its retry buffer

[pigri]

Why

enable_retry_buffering fixes the retry buffer at BODY_BUF_LIMIT (64 KB), and get_retry_buffer returns None once that is exceeded. A request body larger than 64 KB therefore cannot be replayed.

Raising the constant is not a workable alternative: the proxy calls enable_retry_buffering for every request, so a larger default would make every deployment start retaining request bodies up to the new ceiling.

What

enable_retry_buffering_with_limit(limit) -> bool, alongside the existing call. It creates the buffer at the requested capacity, or widens one that has not started filling. The 64 KB default is untouched.

The boolean is the important part. Widening after bytes have landed cannot recover what was already dropped, so a buffer that holds data — or one already truncated — refuses the change and returns false, rather than claiming to hold a whole body when it holds a prefix. A caller that intends to read a body and rely on replaying it must check this and fall back to streaming when it is false.

Added on v1, v2 and subrequest sessions plus the Session enum, and defaulted on the custom Session trait so existing implementors are unaffected.

Motivating case

A proxy that inspects a request body before letting it reach the upstream has to read the body itself. Without a replayable buffer, the upstream request goes out with a Content-Length it never satisfies — the connection aborts with PrematureBodyEnd and the upload hangs until it times out.

Testing

Three unit tests on FixedBuffer: a raised capacity retains a body the default would truncate; a resize is refused once data has landed; a resize is refused after truncation and the buffer stays truncated.

cargo test -p pingora-core --lib passes, cargo fmt --check and cargo clippy -p pingora-core are clean.

No behaviour change for any existing caller — nothing calls the new method in this PR.

[linear-code]

MAN-22