TLDR: if someone drops their hashed shard key index on v5.0 (allowed after BACKPORT-17353) they will be unable to upgrade to FCV 6.0 without rebuilding that index.

During upgrade to v6.0, we add the number of orphan documents to each range deletion task to support balancing by data size rather than number of chunks. We determine the number of orphan documents by scanning the shard key index - this means that if the shard key index does not exist, we will throw an error which will block FCV upgrade.

However, the backport of SPM-3398 allowed for customers to delete their shard key index if they are using hashed sharding. SERVER-79632 considered the case where the user still has range deletion tasks for a collection and removes the index and decided to keep these range deletion tasks around (in case the user re-adds the index in the future and the orphans can be deleted). This means that there is a completely legitimate upgrade case where there are range deletion tasks and no shard key index.

We should handle this case in setOrphanCountersOnRangeDeletionTasks either by skipping setting the orphan counter on the range deletion task if the shard key is hashed and there is no index (note that if the user re-adds the index and balancing begins, this could cause incorrect balancing decisions before the range deletions complete) or by doing a collection scan in case the index doesn't exist to get the orphan count (note that this could be very slow and in the case the user never recreates the index, entirely unneccesary).