Ensure that all lock fds are close-on-exec, fixing various problems with them being inherited by child processes such as git commands.

(With the exception of daemon pid locking.)

This fixes at part of #758630. I reproduced the assistant locking eg, a
removable drive's annex journal lock file and forking a long-running
git-cat-file process that inherited that lock.

This did not affect Windows.

Considered doing a portable Utility.LockFile layer, but git-annex uses
posix locks in several special ways that have no direct Windows equivilant,
and it seems like it would mostly be a complication.

This commit was sponsored by Protonet.

Annex/LockFile.hs

@@ -37,6 +37,7 @@ lockFileShared file = go =<< fromLockPool file
 		mode <- annexFileMode
 		lockhandle <- liftIO $ noUmask mode $
 			openFd file ReadOnly (Just mode) defaultFileFlags
+		setFdOption lockhandle CloseOnExec True
 		liftIO $ waitToSetLock lockhandle (ReadLock, AbsoluteSeek, 0, 0)
 #else
 		lockhandle <- liftIO $ waitToLock $ lockShared file
@@ -70,13 +71,19 @@ changeLockPool a = do
 withExclusiveLock :: (Git.Repo -> FilePath) -> Annex a -> Annex a
 withExclusiveLock getlockfile a = do
 	lockfile <- fromRepo getlockfile
+	liftIO $ hPutStrLn stderr (show ("locking", lockfile))
+	liftIO $ hFlush stderr
 	createAnnexDirectory $ takeDirectory lockfile
 	mode <- annexFileMode
-	bracketIO (lock lockfile mode) unlock (const a)
+	r <- bracketIO (lock lockfile mode) unlock (const a)
+	liftIO $ hPutStrLn stderr (show ("unlocked", lockfile))
+	liftIO $ hFlush stderr
+	return r
   where
 #ifndef mingw32_HOST_OS
 	lock lockfile mode = do
 		l <- noUmask mode $ createFile lockfile mode
+		setFdOption l CloseOnExec True
 		waitToSetLock l (WriteLock, AbsoluteSeek, 0, 0)
 		return l
 	unlock = closeFd