Certain interleaving can lead a configsvr that recently transitioned from catalogShard to dedicated to believe that it owns chunks for collections that have been dropped.

The buggy interleaving is the following:
1. [drop] DropCollectionCoordinator first deletes the sharding metadata for the dropped collection on the configsvr (config.collections and config.chunks).
2. [removeShard] At this point, removeShard will see that there are no more chunks on the draining shard, so it can proceed to remove it from config.shards.
3. [drop] DropCollectionCoordinator now will broadcast _shardsvrDropCollectionParticipant to all the shards (which now does not include the catalogShard anymore, because it has been removed). This is the command that would have made the catalogShard aware that the sharding metadata has changed.

SERVER-87137 made the DropCollectionCoordinator explicitly consider the configsvr a participant for the purposes of releasing the critical section. In the same spirit, we should also consider the configsvr as a participant for the purposes of sending the _shardsvrDropCollectionParticipant command. -Alternatively, we could make the DropCollectionCoordinator first send _shardsvrDropCollectionParticipant to participants before dropping the chunk metadata from the configsvr (That would require some extra rework as _shardsvrDropCollectionParticipant refreshes the collection metadata at the end, which at that point would not yet reflect the post-drop state)-