cmd/go/internal/lockedfile: TestSpuriousEDEADLK flaky on plan9-arm since Oct. 7

[bcmills]

I'm not sure whether this is due to a change in the builder or a change in the runtime or standard library, but lockedfile.TestSpuriousEDEADLK has been failing sporadically on the plan9-arm builder, apparently due to the failure of a *lockedfile.File to provide the expected mutual-exclusion when open for writing.

The first such failure occurred at CL 260137, but it's not obvious to me how that could be related. (The plan9-386-0intro builder started working again around then — do the -386-0intro and -arm builders share an underlying filesystem?)

CC @millerresearch @fhs @0intro

--- FAIL: TestSpuriousEDEADLK (0.04s)
    lockedfile_test.go:255: Edit B unexpectedly did not block

2020-10-12T18:31:36-8994607/plan9-arm
2020-10-12T18:31:29-112c4d5/plan9-arm
2020-10-12T18:31:10-7b77ff4/plan9-arm
2020-10-12T18:31:01-5acec48/plan9-arm
2020-10-12T16:12:25-349a287/plan9-arm
2020-10-10T00:55:54-d317ba5/plan9-arm
2020-10-09T02:49:19-2be7788/plan9-arm
2020-10-09T02:14:32-8f26b57/plan9-arm
2020-10-09T01:09:06-f8df205/plan9-arm
2020-10-07T20:18:43-3f7b4d1/plan9-arm
2020-10-07T18:56:58-5c1567c/plan9-arm
2020-10-07T14:57:54-67edc0e/plan9-arm

[0intro]

While the plan9/386 builder is currently running a local ramfs (an "in memory" file system), I think the plan9/arm builders import their file system from a remote file server, so it may behave differently.

[millerresearch]

In this test the file being locked is in /tmp, which the plan9_arm builders also mount on ramfs.