casblob: reuse the compressed-output buffer to cut upload memory churn

[mjonss]

Problem

Under a burst of concurrent uploads, bazel-remote can suffer a large transient heap overshoot (and OOM on memory-constrained hosts) despite small steady-state memory. alloc_space heap profiling attributes the bulk to zstd.(*Encoder).encodeAll, reached via casblob.WriteAndClose.

Root cause

The zstd write path compresses each blob in 1 MiB chunks and called EncodeAll(in, nil) per chunk, allocating a fresh output slice for every chunk of every upload. The chunk size is exactly 1<<20, and klauspost's EncodeAll only pre-allocates an output buffer when len(src) < 1<<20 (strictly less-than). A full 1 MiB chunk therefore starts from a nil dst and grows it by repeated append-doubling — several MiB of transient garbage per chunk.

Fix

Thread a reusable dst through zstdimpl.EncodeAll (both the pure-Go and cgo backends already accept one) and have casblob.WriteAndClose allocate a single output buffer, sized to compressBound(chunkSize), reused across all chunks of the blob. Sizing to the ZSTD_compressBound worst case guarantees EncodeAll never has to grow (and reallocate) the buffer, even for incompressible chunks whose compressed output is slightly larger than the input.

This complements #775 (which pooled the input chunk buffer) by removing the per-chunk output allocation, and is complementary to #475 (which tunes the encoder's internal memory rather than the output buffer).

Numbers

BenchmarkWriteAndCloseZstd (16 MiB blob, incompressible data), added in this PR:

	B/op	allocs/op
before	~82.8 MB	215
after	~1.1 MB	20

All existing tests pass.

[mjonss]

I found this while setting up bazel-remote on a small node with limited memory, and it had OOM issues, so after investigating I came up with this PR.

[mjonss]

I decided to make a smaller change, instead of using a sync.Pool since the benefit was very good to start with for my use case. If you find it better to also include a sync.Pool also for the compressedChunkBuffer as it already is for uncompressedChunk, I'm happy to add that too.

[mostynb]

Thanks- this looks pretty good, I'm a little worried that the go zstd library might not provide a guarantee on the upper limit of the size of the compressed output. Maybe we should ask Klaus?