Add BytesMut::try_shrink_to_fit and BytesMut::try_shrink_to_capacity

[tsharp]

Fixes BytesMut::try_shrink_to_fit when the BytesMut is an offset view into its backing allocation.

Previously, the implementation called Vec::shrink_to_fit while preserving the current offset into the allocation. That caused incorrect behavior for split/advanced buffers, including:

• returning true while leaving capacity larger than the current length
• panicking from capacity underflow when a split tail started past the initialized length

The fix normalizes the live byte range to the start of the backing Vec before shrinking, then updates the handle to point at the new base allocation.

Tests

Added coverage for:

• shrinking the tail after split_off
• shrinking the front after dropping the split tail
• split tails that start past the initialized length
• vec-backed offset views after advance
• empty vec-backed offset views
• outstanding BytesMut and frozen Bytes references

Validated with:

cargo test try_shrink_to -- --nocapture
cargo test
cargo +nightly miri test try_shrink_to

Why

While using tokio-postgres with deadpool, we noticed increased memory usage from buffer allocations in these libraries. These buffers are pre-allocated when a connection is created and live until that connection is closed.

For applications with only a few connections, or with consistently small result sets, this usually is not a problem. However, applications with many long-lived connections can accumulate a large amount of retained buffer capacity. If some of those connections occasionally handle large reads or writes, the associated BytesMut buffers can remain inflated for the rest of the connection lifetime, leading to significant memory overuse, sometimes multiple gigabytes depending on the application.

Adding try_shrink_to_fit and try_shrink_to_capacity instead of creating a new BytesMut for each request/response ideal over adding potentially significant churn in downstream codebases.

References:

• Memory leak in long-lived connection pool rust-postgres/rust-postgres#1081
• Add documentation for long-lived Postgres pools deadpool-rs/deadpool#273
• Proxy memory leak over HTTP 1 linkerd/linkerd2#11012
• Memory Leak on Actix 3.2.0 actix/actix-web#1780
• docs: unclear how to free memory from a bytesmut #634