Use blocking file locking for cache lock

[bgamari]

Previously the cache lock operation
(Hackage.Security.Client.Repository.Cache.lockCache) would try once to
lock the cache directory and fail if the lock was already held.
This leads to spurious failures in cabal-install due to its concurrent
package fetching behavior.

In this case it's perfectly sensible to rather block.

[dcoutts]

LGTM.

[bgamari]

Note that this should work fine with cabal-install's concurrent fetching functionality. To see why consider downloadPackage:

downloadPackage rep@Repository{..} pkgId dest = withMirror rep $ withIndex rep $ \IndexCallbacks{..} -> runVerify repLockCache $ do ...

The failing lock acquisition here was due to repLockCache. However, this lock is not held for the entire duration of the body enclosed by runVerify. Rather, it is only held when the finalizers of this block are run (e.g. when the downloaded file is copied into its final destination).

[bgamari]

Who is able to merge this?

[hvr]

I wonder whether the locking behaviour should rather be configurable; I can imagine situations in which I'd rather want cabal to give up after some amount of time than to block indefinitely on a stuck lock...