Version vector related extensions to the recovery restart logic

[sbodagala]

Version vector/Unicast specific: Restart recovery if the list of available tLogs change in such a way that the current in-progress recovery could stall.

More details: Let "listA" be the list of known locked tLogs of the current in-progress recovery. Suppose the list of known locked tLogs change and "listB" be the current list. If "listA" is not a subset of "listB" then there is a chance that the current in-progress recovery would stall, hence restart recovery (even if the recovery version hasn't changed).

We don't need to restart recovery in "main" in this case because the cursor logic tracks these changes (code:

foundationdb/fdbserver/LogSystemPeekCursor.actor.cpp

Line 1155 in d45a17b

q.push_back(c->onFailed());

) and can reset "bestServer" after that (code:

foundationdb/fdbserver/LogSystemPeekCursor.actor.cpp

Line 1120 in d45a17b

if (self->bestServer >= 0 && self->bestSet >= 0 &&

) (this is what I think happens in "main", I haven't verified it by going through a simulation test). We can't dynamically change "bestServer" when version vector/unicast is enabled (because we explicitly specify "returnEmptyIfStopped" flag based on whether "bestServer" is enabled or not at the time the cursor is built, code:

foundationdb/fdbserver/LogSystemPeekCursor.actor.cpp

Line 898 in d45a17b

((SERVER_KNOBS->ENABLE_VERSION_VECTOR_TLOG_UNICAST && end != std::numeric_limits<Version>::max())

) and hence we need to restart recovery in this case.

Testing:
Joshua id (with version vector disabled): 20250730-232250-sre-7ba451e103463247 (started).

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: 6af5f13
• Duration 0:40:09
• 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: 6af5f13
• Duration 0:48:27
• 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: 6af5f13
• Duration 1:12: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)

[foundationdb-ci]

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

• Commit ID: 6af5f13
• Duration 1:14:45
• 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)

[foundationdb-ci]

Result of foundationdb-pr on Linux RHEL 9

• Commit ID: 6af5f13
• Duration 1:15:37
• 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)

[dlambrig]

could add an event, something like:

if (knownLockedTLogIdsChanged) {
    TraceEvent("KnownLockedTLogsChanged")
        .detail("Last", describe(lastKnownLockedTLogIds))
        .detail("Current", describe(currentKnownLockedTLogIds));
}

[dlambrig]

nit: no need to lookup keyA twice, can do a single lookup.

auto it = mapB.find(keyA);
if (it == mapB.end()) {
    return false;
}
const auto& valueB = it->second;

[dlambrig]

to save a future headache, add
currentKnownLockedTLogIds.clear(); // ensures safety if accessed later

[dlambrig]

for clarity, and since this is not really a generic function, could rename keyA to locality (or log to be consistent with caller, but I think "log" is misleading).

mapA could become lastLockedTLogs and mapB could be newLockedTLogs, or something similar.