…enames

os.Rename is not atomic on Windows, although in practice it seems to
be mostly-atomic most of the time. At the very least, this should
substantially reduce the maintner failure rate for Windows users (if
there are any) and on the windows-amd64-longtest builder.

It would be better still to refactor netMutSource to avoid assuming
that rename is atomic and to do something else instead, like appending
to the file's final location and using the file's length or checksum
to check for completeness, or using file-locking (which does work on
Windows, at least on NTFS filesystems) instead.

(This change, in contrast, seems like the shortest path to something
that works well enough to pass on the builders.)

For golang/go#36163

Change-Id: Iad20d284d1dde798df66d1b493193e646cd70c4d
Reviewed-on: https://go-review.googlesource.com/c/build/+/361334
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>