Workaround for completely broken file locking on Windows 10 WSL.

WSL (Windows Services for Linux) provides a Linux-kernel-compatible ABI
for userspace processes, but the current version doesn't not implement
fcntl() locks at all; it just always returns success.  See
https://github.com/Microsoft/WSL/issues/1927.

This causes us three kinds of problem:
  1. sqlite3 in WAL mode gives "OperationalError: locking protocol".
     1b. Other sqlite3 journal modes also don't work when used by
         multiple processes.
  2. redo parallelism doesn't work, because we can't prevent the same
     target from being build several times simultaneously.
  3. "redo-log -f" doesn't work, since it can't tell whether the log
     file it's tailing is "done" or not.

To fix #1, we switch the sqlite3 journal back to PERSIST instead of
WAL.  We originally changed to WAL in commit 5156feae9d to reduce
deadlocks on MacOS.  That was never adequately explained, but PERSIST
still acts weird on MacOS, so we'll only switch to PERSIST when we
detect that locking is definitely broken.  Sigh.

To (mostly) fix #2, we disable any -j value > 1 when locking is broken.
This prevents basic forms of parallelism, but doesn't stop you from
re-entrantly starting other instances of redo.  To fix that properly,
we need to switch to a different locking mechanism entirely, which is
tough in python.  flock() locks probably work, for example, but
python's locks lie and just use fcntl locks for those.

To fix #3, we always force --no-log mode when we find that locking is
broken.

t/010-jobserver/all.do

@@ -6,6 +6,11 @@ redo -j1 serialtest
 
 # Capture log output to parallel.log to hide the (intentional since we're
 # testing it) scary warning from redo about overriding the jobserver.
+if [ -n "$REDO_LOCKS_BROKEN" ]; then
+	echo "Locks are broken on this OS; skipping parallel tests." >&2
+	exit 0
+fi
+
 echo 'parallel test...' >&2
 if ! redo -j10 paralleltest 2>parallel.log; then
 	cat parallel.log >&2

t/010-jobserver/paralleltest.do

@@ -3,5 +3,5 @@
 # sharing with other tests, we can't be sure that parallel2 will run while
 # parallel is running, and the race condition will make this test at least
 # be flakey instead of pass, which means there's a bug.)
-rm -f *.sub *.spin *.x *.log parallel *.start *.end
+rm -f *.sub *.spin *.x parallel *.start *.end
 redo parallel parallel2

t/010-jobserver/serialtest.do

@@ -1,4 +1,3 @@
 # Test that -j1 really serializes all sub-redo processes.
 rm -f *.sub *.spin *.x first second *.start *.end
 redo first second
-