fix(buffers): make disk buffer record reads cancel-safe - #27163

Summary

A memory buffer with when_full: overflow into a disk buffer never drains the disk stage while the memory stage keeps receiving events. Spilled events stay on disk until a restart, or are never delivered.

BufferReceiver::next polls the disk reader inside select! against the memory stage and drops the disk read future whenever the memory stage wins. RecordReader::try_next_record is not cancel-safe: it reads the length delimiter, then fills aligned_buf over several fill_buf/consume calls. When the future is dropped in between, the bytes already consumed are gone, and the next call reads the middle of a record as a length delimiter. The reader then fails on garbage or waits for data that never arrives.

This PR keeps the length of the record being collected in pending_record_len, so a cancelled try_next_record resumes the same record instead of starting over. The buffer is reset only when a new record starts, and the pending state is cleared on errors and once the record is complete.

References

Closes: #20322
Related: #24304
Related: #26033 (touches the same reader; it does not change record-read cancellation, so the two should compose)

Vector configuration

sinks:
  influx:
    type: influxdb_logs
    # ...
    buffer:
      - type: memory
        max_events: 2000
        when_full: overflow
      - type: disk
        max_size: 268435488
        when_full: drop_newest

How did you test this PR?

• New test overflow_disk_stage_drains_while_memory_stage_is_live in topology/channel/tests.rs: spills records to the disk stage, then keeps the memory stage live and asserts that every spilled record is delivered without recreating the buffer. It fails on master and passes with this change.
• cargo test -p vector-buffers passes. known_errors::writer_detects_when_last_record_has_scrambled_archive_data is flaky with and without this change.
• On an aarch64 edge device (0.57.0 with this patch, ~29 events/s per sink, two InfluxDB sinks), the outbound traffic was blocked with iptables:
  • Stock 0.57.0: the memory stage filled to 2000 and the disk stage to ~2500. After unblocking, the memory stage drained immediately, but the disk stage stayed at ~1700 events for the full 5 min observation while live events kept flowing.
  • Patched: same outage (5 min, disk stage ~5500). Both stages were at 0 within 10 s after unblocking, without a restart. Every event arrived and the series in InfluxDB has no gap.
  • Patched, systemctl restart vector in the middle of the outage: the disk stage contents survived the restart and were delivered after unblocking.
  • Restarting the stock instance on the patched build drained its stuck disk stage within a minute.

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the no-changelog label to this PR.