What's the issue

The issue is that `ShardingCoordinatorService` waits for all `MoveRangeCoordinator` instances to finish before marking the RangeDeletion recovery job as complete.
As a result, if a new `MoveRangeCoordinator` starts before a previous one has been destroyed (which can happen for different namespaces), and the new coordinator runs with `_waitForDelete: true`, the system can deadlock:

• the `MoveRangeCoordinator` waits for range deletion to complete;
• range deletion cannot start until the recovery job is cleared; and
• the recovery job is not cleared until the `MoveRangeCoordinator` instance is

A little bit of context about how RangeDeletion recovery jobs work

During step-up, a recovery job for range deletions is always registered at sharding_initialization_mongod.cpp:L668. The ShardingCoordinatorService infrastructure is responsible for marking this job as completed (see here and here), either when there are no MoveRangeCoordinators to recover or, if one exists, once its recovery finishes. Range deletions cannot start until the number of recovery jobs reaches 0.