After a successful migration, the donor shard will schedule a task to submit the moved away range for deletion in the MetadataManager. To enable migrations with waitForDelete=true, a future for submitting this deletion task is returned to the MigrationSourceManager and waited on to guarantee the task is in the MetadataManager before the MSM waits for it to remove that range (to avoid the race from SERVER-45917).

The logic for storing the future in the MSM is somewhat convoluted, and ideally wouldn't be necessary. This ticket is to refactor how ranges that have been scheduled to be submitted are handled to avoid this. One approach could be to have standalone "RangeDeletionService" type class that owns (UUID, range) pairs that have been submitted for deletion outside the MetadataManager, which the MSM can consult instead.