Fix race condition in DoubleLocked#release

[alexarchambault]

This PR makes some uses of DoubleLock safer, and fixes a race condition with it.

DoubleLock is basically used as a wrapper around a file lock (second lock), using it alongside a memory lock (first lock), that acts as a mutex for it. That way, the same JVM process doesn't try to acquire the file lock twice at the same time in a given JVM, which java.nio.channels.FileChannel doesn't allow (it throws an OverlappingFileLockException in that case).

This PR makes sure MillMain and MillDaemonMain use the same Lock.memory() instance as a guard when trying to acquire a lock for the output directory. This doesn't solve the issue I was running into (see below), but seems to be safer nonetheless.

It also tries to dispose of locks in DoubleLock in case calls to Lock#{lock,tryLock} throw.

Lastly, it releases the two locks in DoubleLocked in the reverse order that they were acquired. This fixes the test case below. Doing so fixes a race condition, where

• a first thread acquires the lock
• a second one tries to acquire it, and waits for it
• the first thread releases the lock

During the third step, releasing the memory lock before the file lock makes the second thread acquire the memory lock, and then possibly try to acquire the file lock, before the first thread is done releasing the file lock. The JVM doesn't allow this, and the second thread gets an OverlappingFileLockException.

See the discussion in #5152 too

This fixes

$ ./mill 'integration.feature[output-directory].packaged.daemon.testForked' "mill.integration.OutputDirectoryLockTests.basic"

for me, locally.

[lihaoyi]

@alexarchambault can you fill out the PR description with your understanding of the problem and why this is the correct fix for it

[alexarchambault]

@lihaoyi Should be done

[lihaoyi]

shipit