Windows doesn't have a python3 executable, so cc0b332ab9fc attempted to work
around the issue by copying the current python to python3.exe. That put it in
_tmpbindir because of failures in test-run-tests.t when using _bindir,
which looked like a process was trying to open it to write out a copy while it
was in use. (Interestingly, I couldn't reproduce this running the test by
itself in a loop for a couple of hours, but it happens constantly when running
all tests.) The problem with using _tmpbindir is that it is the randomly
generated path for the test run, and instead of Windows Firewall remembering the
executable signature or image hash when allowing the process to open a server
port, it apparently remembers the image path. That means every run will trigger
a popup to allow it, which is bad for firing off a test run and walking away.
I tried to symlink to the python executable, but that currently requires admin
priviledges. This will prompt the first time if the underlying python binary
has never opened a server port, but appears to avoid it on subsequent runs.