os/exec: Cmd.String races with Cmd.Start on Windows

[bcmills]

https://go.dev/cl/527337 reverted a change in os/exec due to a data race between the Start method and anything that inspects the Path field of the Cmd, notably including its String method.

https://go.dev/cl/527495 attempts to add a regression test for that data race, but currently fails on Windows because the data race is still present there.

The race appears to have been introduced in https://go.dev/cl/83020043, which added logic to update the Path field to reflect the resolved extension of the requested path. However, some of the regression tests added in that change are already failing in some circumstances (#62594).

In light of those failing tests, I believe we should resolve the race by no longer updating the Path field.

(CC @golang/windows, @ianlancetaylor)

[ianlancetaylor]

I wonder if it would make sense to update the Path field in exec.Command.

[bcmills]

I think it would, but there are some corner cases where that will be a slightly incompatible change. (I have a stack with a bunch of test cleanup and most of a fix, but couldn't get it quite done today because my gopls is having fits of hanging and deadlocking. 😞)

[gopherbot]

Change https://go.dev/cl/528035 mentions this issue: os/exec: simplify Windows-specific tests

[gopherbot]

Change https://go.dev/cl/527820 mentions this issue: os/exec: avoid writing to Cmd.Path in Cmd.Start on Windows

[gopherbot]

Change https://go.dev/cl/528038 mentions this issue: os/exec: avoid calling LookPath in cmd.Start for resolved paths

[gopherbot]

Change https://go.dev/cl/548481 mentions this issue: doc: document os/exec changes on Windows