persist: add turmoil-enabled consensus and blob implementations

[teskje]

This PR introduces Consensus/Blob implementations that both forward commands over a turmoil::net::TcpStream to a server task that's a thin wrapper around the Mem* implementations. This is to support persist simulation in turmoil tests, which can now crash the consensus/blob servers, and introduce network faults in the persist communication.

The new implementations are gated behind a "turmoil" feature.

Motivation

• This PR adds a feature that has not yet been specified.

Support simulating persist in turmoil-based tests.

Tips for reviewer

Here this is used in action: #34110

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[bkirwi]

I was a little surprised that turmoil doesn't give us a nice way to have workers interleave / interact outside these managed tcp streams, but that does seem like the right way to model it here, and the implementations themselves are pretty clean! Thanks for keeping the feature well-segregated.

[teskje]

I was a little surprised that turmoil doesn't give us a nice way to have workers interleave / interact outside these managed tcp streams

Yeah, turmoil's main thing is network simulation, and it expects that nodes only communicate through the turmoil TcpStreams. Though I think there is nothing fundamental that prevents it from exploring more node interleavings (tasks in a single node is hard because you'd need to reach into tokio to control that). There is already enable_random_order, and if that turns out insufficient, we can consider adding ways to pause nodes explicitly or randomly.

[teskje]

TFTR!