Optimize read buffer compaction and reduce copying

[zuiderkwast]

Do compaction of the read buffer (memmove) before feeding more data to the reader, instead of after each parsed command.

Previously, sdsrange() was called in valkeyReaderGetReply() to compact the read buffer after consuming >= 1024 bytes. With pipelining, GetReply is called many times per Feed call (once per reply), causing repeated memmove() operations on the remaining buffer data.

Move the compaction to valkeyReaderFeed(), right before appending new data. This ensures the memmove happens at most once per network read instead of once per parsed reply.

Additionally, make space in the allocated read buffer before the read() call and read directly into the allocated reply buffer instead of copying it via a static buffer. A public API for this is added (valkeyReaderGetReadBuf + valkeyReaderCommitRead).

Profiling

Profiled using valkey-benchmark on macOS (Apple M4 Pro) with:

valkey-benchmark -P 32 -d 1024 -r 1000000 -n 3000000 -c 50 -t set,get

Server ran with --io-threads 4 to avoid being server-bottlenecked.

Flamegraph sampling (macOS sample tool, 10s at 1ms intervals) of the valkey-benchmark process shows the following top userspace hotspots:

Read path hotspot	Original	After compaction fix	After direct read
sdsrange → memmove (GetReply)	250	0 ← eliminated	0
valkeyReaderFeed → sdscatlen → memmove	38	43	0 ← eliminated
__recvfrom (kernel)	246	266	295
createStringObject → memmove	25	27	28

After the first change, the sdsrange memmove (250 samples) is eliminated and the compaction cost is absorbed into valkeyReaderFeed with negligible overhead increase (38 -> 43 samples). After the second change, the sdscatlen -> memmove is also eliminated.

[zuiderkwast]

I added another optimization: direct read into the allocated reply buffer instead of via a static buffer.

Read path hotspot	Original	After compaction fix	After direct read
sdsrange → memmove (GetReply)	250	0 ← eliminated	0
valkeyReaderFeed → sdscatlen → memmove	38	43	0 ← eliminated
__recvfrom (kernel)	246	266	295
createStringObject → memmove	25	27	28

The sdscatlen copy in the read path (previously 38-43 samples) is now zero — data goes directly from the kernel into the reader's sds buffer. The kernel
syscall samples went up proportionally since it's now a larger share of the remaining work.

The two optimizations combined eliminated the top two userspace hotspots in the read path. What remains is dominated by syscalls and the inherent cost of
creating reply objects.