Rename participants are snapshotting range deletions by namespace before restoring them. This results in:

• Not using an index while scanning config.rangeDeletions that only has a {collectionUUID, min, max} secondary index
• Snapshotting multiple times the same ranges when several renames are executed back and forth between the same namespaces (as in some FSMs) (solved by SERVER-83454)
  • This means exponentially incrementing the number of range deletion documents, making subsequent renames on the same collection slower over time (solved by SERVER-83454)