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.

Remote/Git.hs

@@ -436,9 +436,10 @@ dropKey' repo r st@(State connpool duc _ _ _) key
 		( guardUsable repo (giveup "cannot access remote") $
 			commitOnCleanup repo r st $ onLocalFast st $ do
 				whenM (Annex.Content.inAnnex key) $ do
-					Annex.Content.lockContentForRemoval key $ \lock -> do
+					let cleanup = logStatus key InfoMissing
+					Annex.Content.lockContentForRemoval key cleanup $ \lock -> do
 						Annex.Content.removeAnnex lock
-						logStatus key InfoMissing
+						cleanup
 					Annex.Content.saveState True
 		, giveup "remote does not have expected annex.uuid value"
 		)