Make log servers return an empty version range only when it is correct to do so

[sbodagala]

In the context of version vector/unicast, make log servers return an empty version range (on peeks) only when it is correct to do so. This is so the receiver will receive all versions (even though the sender is sending an empty version range) that it is supposed to receive.

Changes:

• Make the cluster controller collect the set of log servers participated in recovery and propagate that information to the other processes.
• Extend the ServerPeekCursor to take a flag that tells the source log server whether it can return an empty version range or not (in the context of version vector/unicast), and make the source log server return an empty version range only when this flag is set.
• Make the peek APIs set the flag appropriately when initializing ServerPeekCursors.
• Also, take the internal logic used by SetPeekCursor and MergedPeekCursor into account while initializing the above mentioned flag.

Testing:

Joshua id (with version vector disabled): 20250609-200159-sre-0c15ba89fee21207 (no failures).

Code-Reviewer Section

The general pull request guidelines can be found here.

Please check each of the following things and check all boxes before accepting a PR.

• The PR has a description, explaining both the problem and the solution.
• The description mentions which forms of testing were done and the testing seems reasonable.
• Every function/class/actor that was touched is reasonably well documented.

For Release-Branches

If this PR is made against a release-branch, please also check the following:

• This change/bugfix is a cherry-pick from the next younger branch (younger release-branch or main if this is the youngest branch)
• There is a good reason why this PR needs to go into a release branch and this reason is documented (either in the description above or in a linked GitHub issue)

[foundationdb-ci]

Result of foundationdb-pr-clang-ide on Linux RHEL 9

• Commit ID: 4ec7e4d
• Duration 0:25:38
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x

• Commit ID: 4ec7e4d
• Duration 0:38:58
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-clang-arm on Linux CentOS 7

• Commit ID: 4ec7e4d
• Duration 0:49:23
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-clang on Linux RHEL 9

• Commit ID: 4ec7e4d
• Duration 0:51:22
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr on Linux RHEL 9

• Commit ID: 4ec7e4d
• Duration 0:59:47
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-cluster-tests on Linux RHEL 9

• Commit ID: 4ec7e4d
• Duration 1:01:39
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)
• Cluster Test Logs zip file of the test logs (available for 30 days)

[dlambrig]

todo - do both these have to be optional?

[sbodagala]

TagPartitionedLogSystem::peekLogRouter(), an invoker of this, takes these arguments as Optional. Outside the recovery context, I don't think these arguments need to be specified so I think it makes sense to have these as optional. Also I plan to feed the locked server list from the serialized TagPartitionedLogSystem to this method from TagPartitionedLogSystem::peekLogRouter() in a follow up PR, so I think it makes sense to have this argument as Optional in that sense too. The "Optional end" argument has a value assigned to it in both the contexts that this method is currently getting called from, so it may not need to be Optional (but we may not want to change this purely based on the current invokers).