When a sharded collection is dropped, the range-deleter is lazily discovering that some range deletions may refer an older incarnation of such collection (dropped or dropped and recreated).

While de-queueing already scheduled range deletion tasks that may not be trivial, a simple optimization could be to delete persistent range deletion task documents so that:

• On step-up, "stale" range deletion tasks are not getting scheduled
• Users and technical services don't get fooled by the presence of wrong range deletion tasks
• It would be consistent with rename that already drops "stale" range deletion tasks both for source and target collection

This change is safe because the range-releter is already handling the absence of a document for a scheduled range deletion.