avoid failure to lock content of removed file causing drop etc to fail

This was already prevented in other ways, but as seen in commit
c30fd24d91, those were a bit fragile.
And I'm not sure races were avoided in every case before. At least a
race between two separate git-annex processes, dropping the same
content, seemed possible.

This way, if locking fails, and the content is not present, it will
always do the right thing. Also, it avoids the overhead of an unncessary
inAnnex check for every file.

This commit was sponsored by Denis Dzyubenko on Patreon.

Command/Move.hs

@@ -155,7 +155,7 @@ toPerform dest removewhen key afile fastcheck isthere =
 		RemoveNever -> do
 			setpresentremote
 			next $ return True
-		RemoveSafe -> lockContentForRemoval key $ \contentlock -> do
+		RemoveSafe -> lockContentForRemoval key lockfailed $ \contentlock -> do
 			srcuuid <- getUUID
 			let destuuid = Remote.uuid dest
 			willDropMakeItWorse srcuuid destuuid deststartedwithcopy key afile >>= \case
@@ -188,6 +188,13 @@ toPerform dest removewhen key afile fastcheck isthere =
 		next $ do
 			() <- setpresentremote
 			return False
+	
+	-- This occurs when, for example, two files are being dropped
+	-- and have the same content. The seek stage checks if the content
+	-- is present, but due to buffering, may find it present for the
+	-- second file before the first is dropped. If so, nothing remains
+	-- to be done except for cleaning up.
+	lockfailed = next $ Command.Drop.cleanupLocal key
 
 fromStart :: RemoveWhen -> AssociatedFile -> Key -> ActionItem -> Remote -> CommandStart
 fromStart removewhen afile key ai src =