[ENH][wal3]: add quorum_writer for parallel future coordination

[rescrv]

Description of changes

Implement a quorum-based coordination mechanism that:

• Runs futures in parallel and waits for a minimum count of Ok results
• Starts a timeout after reaching the quorum threshold
• Cancels remaining futures that exceed the timeout
• Returns results in original order with None for cancelled futures

This enables handling partial quorum failures where some writers may
be slow or unresponsive, allowing the system to proceed once a quorum
of successful writes is achieved while still attempting to maximize
replication within a bounded time window.

Test plan

Unit tests + CI

Migration plan

N/A

Observability plan

N/A

Documentation Changes

N/A

Co-authored-by: AI

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[propel-code-bot]

The change introduces a write_quorum helper that is exported for wider WAL consumption and is backed by extensive async tests spanning empty inputs, mixed success and error scenarios, timeout handling, ordering guarantees, and quorum edge cases.

Affected Areas

• rust/wal3/src/quorum_writer.rs
• rust/wal3/src/lib.rs

This summary was automatically generated by @propel-code-bot

[sanketkedia]

So phase1 by design is without a deadline and can get stuck here forever? Would be useful to elaborate through comments here as to the intention

[rescrv]

The individual futures are assumed to be timeout-friendly, as is currently the case with all quorum ops. This gives the ability to control the timeout on a per-future basis without muddying this code.

[propel-code-bot]

[Performance] Since futures is a homogeneous Vec<F>, you can store the generated async blocks directly in FuturesUnordered without type erasure. This removes the need for Pin<Box<dyn Future...>>, saving one heap allocation per future and avoiding dynamic dispatch overhead.

The compiler will generate a single anonymous type for the async move block across all iterations.

Context for Agents

Since `futures` is a homogeneous `Vec<F>`, you can store the generated async blocks directly in `FuturesUnordered` without type erasure. This removes the need for `Pin<Box<dyn Future...>>`, saving one heap allocation per future and avoiding dynamic dispatch overhead.

The compiler will generate a single anonymous type for the `async move` block across all iterations.

File: rust/wal3/src/quorum_writer.rs
Line: 56