Cherry pick PR 7462

When there are no user commits, versions advance at a minimum rate governed by knob MAX_COMMIT_BATCH_INTERVAL. FDB needs continuously generated commits, e.g. in shard movement where new versions are "piggy backed" to make progress.

The actors commitBatcher and commitProxyServerCore generate these commits. The problem is they run asynchronously to each other and can get out of sync. The former times out every MAX_COMMIT_BATCH_INTERVAL seconds and wakes the later, which may have sent an empty message less than MAX_COMMIT_BATCH_INTERVAL seconds ago (it may have delayed the previous commit). In that case, commitProxyServerCore won't send the empty commit, and a new commit won't be generated until commitBatcher times out again.

This pattern delays version advancement up to MAX_COMMIT_BATCH_INTERVAL*2 seconds and breaks the knob's contract. Shard movement is slowed, eventually leading to the failure in quiet database.

This PR makes a single actor (commitBatcher) regulate the frequency of empty commits.

Fixes
MutationLogReaderCorrectness.toml -b on -s 653691063;
MutationLogReaderCorrectness.toml -b on -s 98766466
etc. (more).

Joshua
20220701-220644-henrylambright-f99f08bd5fb313ef

Code-Reviewer Section

The general 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)