Track shard moves for version vector

[dlambrig]

With version vector, store the most recent version that modified the shard map on the resolvers, and include this value on replies back to the CP. On commits, the CP sends to the RV what it thinks is the most recent version of a shard change. If the CP is behind the RV, it is unaware of the latest shard change and may have the wrong set of tags; send the commit to all logs.

(This PR is in draft, as it is overly conservative)

---

scenario

1. Two transactions on the same CP access the same shard map.
2. Transaction 1: Modifies the shard map on the resolver and then completes, updating the shard map on the CP.
3. Transaction 2: Before Transaction 1 returns from the resolver, reads tags for the shard using the old shard map (pre-resolution).
4. Transaction 1 completes, now the shard map is updated on the CP.
5. Transaction 2 uses the outdated tags (from the old shard map) to get locations from the resolver (same RV as transaction 1).
6. Transaction 2 returns and accesses the updated shard map on the CP, leading to a mismatch between the chosen shard and the previously retrieved tags.

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 CentOS 7

• Commit ID: dbf1126
• Duration 0:24:19
• 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: dbf1126
• Duration 0:38:33
• 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: dbf1126
• Duration 0:48:41
• 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 CentOS 7

• Commit ID: dbf1126
• Duration 0:51: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 CentOS 7

• Commit ID: dbf1126
• Duration 1:00:34
• 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 CentOS 7

• Commit ID: dbf1126
• Duration 1:14:06
• 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)