Shard diff transfer integration

[timvisee]

Tracked in: #3477
Depends on: #3551, #3571

This adds a new WalDelta shard transfer method to allow shard diff transfers. This variant remains unused for now and is hidden by default.

It adds a transfer_wal_delta function to actually drive such transfer from a source node.

The method currently utilizes a queue proxy shard because it already has all the necessary bits and bots implemented for transferring a WAL including all new incoming updates.

Tasks

• Resolve all TODOs
• Prevent physical WAL from being truncated if we diff, even if it has already been truncated of the logical WAL
  We can set a max_ack version now, but this only limits the logical WAL. The physical WAL probably contains important data too which we should not truncate off while we still need it for transferring the diff.
• Merge Allow using queue proxy on WAL in the past #3551
• Merge Resolve WAL delta for shard diff transfer #3571
• Rebase this on dev
• Target this PR to merge into dev
• Undraft this PR

All Submissions:

• Contributions should target the dev branch. Did you create your branch from dev?
• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. Does your submission pass tests?
2. Have you formatted your code locally using cargo +nightly fmt --all command prior to submission?
3. Have you checked your code using cargo clippy --all --all-features command?

[timvisee]

I'll merge this with WAL delta transfers disabled by default. I've confirmed this to work with 1.7 and 1.8 nodes in a single cluster.

For now, a user could explicitly invoke a diff transfer by setting "method": "wal_delta".

The plan is to make automatic WAL delta transfers happen in the 1.8 release, but there are some state problems to resolve. I'd prefer to merge this first so we have something to work with. Automatic WAL delta transfers will be worked on separately.