Background

Since a drop from the DonorStateMachine can happen concurrently with a rename from a RecipientStateMachine on the same node, there's no inherent guarantee of ordering. Thus, there can be two scenarios that the drop functionality can find itself in:

1. If the renameCollection with dropTarget=true happens first, then the drop would see <database>.<collection> has a UUID of reshardingUUID.
2. If the drop happens first, the drop would see <database>.<collection> has a UUID of existingUUID.

Solution

1. If the rename happens first and the collection has a UUID of reshardingUUID, this means that the rename already took care of the drop (via dropTarget=true) and the DonorStateMachine can successfully transition to kDone without taking any action.
2. If the drop happens first and the collection has a UUID of existingUUID, the DonorStateMachine can drop the local collection. This is fine, because when the rename happens afterwards, the rename's dropTarget piece will end up being a no-op.