clonebundle-digest: add recursion guards for Python 3.8 For Python 3.8 and 3.9, the read/readinto pair can recurse, so make sure the data is only hashed once.

tests: replace inline `waitlock()` with `wait-on-file` script The latter scales up the timeout based on the timeout value provided to the test runner, and I was seeing timeouts on Windows when running all of the tests using all CPU cores.

tests: stabilize `test-split-legacy-inline-changelog.t` on Windows The `tar` command is unable to process "C:\path\to\foo.tar" style paths, which is how `$TESTDIR` is constructed. It also didn't work with `$TESTDIR_FORWARD_SLASH`- both failed with: tar: Cannot connect to C: resolve failed [128] But `cat` can handle it if the path is quoted, and `tar` can read from stdin.

tests: stabilize `test-largefiles-cache.t` on Windows The `undo.backup.dirstate.bck` was created by `hg commit -m 'add largefile'` at line 18, and deleted in the conditional block by `hg push -q http://localhost:$HGPORT/` at line 138. That's... surprising, but probably not harmful, and can be debugged from Linux if it is a problem. This was showing up in `find src/.hg/largefiles/* | grep -E "(dirstate|$hash)"`.

tests: stabilize `test-journal.t` on Windows The file in these lines are double quoted, but single quoted on other platforms. Not sure why, other than `cmd.exe` doesn't recognize single quotes. But it's a cosmetic difference, so glob over it and move on.

tests: stabilize `test-clonebundles.t` on Windows The `remote: {foo,bar}` lines were different because `echo` in MSYS uses `\r\n`. I couldn't make it work with the previous echoing of individual lines, changing the internal `echo` to `printf "foo\n"`, because that output as "foon". This works on Linux and Windows, so I'm not thinking too hard about it.

tests: cleanup some special casing of `seq` emitting '\r\n' My guess is these predate the commit referenced in the previous commit.

tests: force `seq` to print with '\n' EOL It looks like consistent EOL is the reason for 0605726179a0, but now on py3, `print()` uses the platform EOL without regard to binary mode. The tests mostly use this to loop over a sequence of number in the shell, but there are a handful that redirect output to a file. Specifically, this fixes Windows runs of `test-bundle2-multiple-changegroups.t`, but there may be other tests this fixes. Some other `tests/*.py` files also set binary mode on stdout, but they also write bytes directly to `sys.stdout.buffer`. I'm not doing that here because PyCharm flags these write calls for passing bytes instead of str (PyCharm is likely wrong, but possibly confused because the code falls back to `sys.stdout` if there is no `.buffer` attribute), and it's annoying.

tests: stabilize `test-bundle-phase-internal.t` on Windows This is a silly difference, and we control the Windows side of things from mercurial/windows.py:195. I'll swap and quote the values to be like `no-windows` at some point, but I suspect this exception output would appear elsewhere, and don't feel like waiting for a 2h+ test run to find all of them.

tests: skip `test-wsgicgi.t` on MSYS The test is attempting to set `PATH_INFO="/rev/\xe2\x80\x94"` into the environment, which it does. The problem is that when MSYS sees a leading '/' in an environment variable, it thinks it's a unix filesystem path, so it "helpfully" prepends the Windows path to the MSYS root directory before running a non-MSYS process. hgweb would then split this value on '/', so it would get 'C:' instead of 'rev', and return a 400 since that isn't a valid web command. I tried generating a *.bat file, but had trouble running that via `cmd.exe` inside the test. I also tried generating an equivalent *.py launcher that would set the environment variables itself. But there is no `os.environb` on Windows, and the value was getting mangled when put into the script. So, I give up. If it's encoding stuff on Windows, it's probably broken.