Ensure file lock is released before cache cleanupCaches with on-demand locking keep hold of file locks unless contendedby other Gradle processes. Prior to this commit, such previouslyacquired file locks were held for the complete duration of cachecleanup only to be released immediately afterwards. While cache cleanupwas running, requests to release such file locks from other processes(via `DefaultFileLockContentionHandler`) were not processed because the`stateLock` of `DefaultCacheAccess` was already locked by anotherthread and thus, the `ContentionAction` in`LockOnDemandCrossProcessCacheAccess` was blocked until the `close()`method in `DefaultCacheAccess` was finished.Since cache cleanup only deletes files that are no longer in use, itdoes not use file locking (which would not work anyway because thecurrent cache access infrastructure is not usable while the cache isalready being closed). Thus, this commit closes the`CrossProcessCacheAccess` of the `DefaultCacheAccess` *before* cleaningup caches.Issue: gradle/gradle-private#1412
Improve file lock contention handlingThis commit improves the likelihood for lock requesters to acquire afile lock after it is released due to contention. After the lock hasbeen released, the former lock holder now sends a packet to the socketsof all requesters. While old clients will simply ignore the additionalpacket, new clients will interpret it as a signal that the file lock hasbeen released and will try to acquire it immediately.Issue: gradle/gradle-private#1412.
Provide an empty contended action instead of nullThis contention handling is already active for exclusive locks, butwithout an action it is ignoring requests from other parties.With this, it sends confirmation that the request was receivedand that lock releasing is in progress. Although the release itselfis not performed by the contended action, but manually after thelock is no longer needed (which is the contract for exclusive locks).