Range deletion of aborted migration can fail after a refine shard key

At the end of _configSvrRefineCollectionShardKey it triggers a best-effort fire-and-forget refresh to the shards that own chunks. It's best effort, so it is not guaranteed that the shards will actually refresh.

Consider a shard that had cached metadata for the collection, but had not successfully refreshed after the refineCollectionShardKey. If this shard is later a recipient of a chunk migration that gets aborted, when this shard goes to execute the range deletion, it will believe the collection still has the old shard key. However, the range boundaries in the task are with the new refined shard key. So this call to KeyPattern::extendRangeBound will fail here .