net: Test{Read,Write}TimeoutFluctuation failures with "took over 1s"

[bcmills]

--- FAIL: TestWriteTimeoutFluctuation (1.09s)
    timeout_test.go:758: Write took over 1s; expected 0.1s
FAIL
FAIL	net	18.272s

2019-12-11T19:51:34-1b1fbb3/solaris-amd64-oraclerel
2019-10-21T16:42:10-7a6da21/solaris-amd64-oraclerel
2019-05-07T18:42:17-dc0388c/solaris-amd64-smartosbuildlet

See also #20838, #10775.

CC @bradfitz @ianlancetaylor

[bcmills]

2020-01-24T19:19:16-e35876e/solaris-amd64-oraclerel
2019-11-12T22:09:05-a56d755/windows-amd64-longtest
2019-11-08T02:40:04-e038c7e/linux-arm64-packet
2019-10-21T16:42:10-7a6da21/solaris-amd64-oraclerel
2019-05-31T21:27:59-c10db03/freebsd-arm-paulzhol
2019-05-07T18:42:17-dc0388c/solaris-amd64-smartosbuildlet

[bcmills]

2020-04-16T17:13:33-d4d2980/darwin-amd64-10_15
2019-12-11T19:51:34-1b1fbb3/solaris-amd64-oraclerel

[bcmills]

2020-12-23T17:30:35-fb96f07/darwin-amd64-10_14
2020-10-23T15:11:03-e223c6c/solaris-amd64-oraclerel
2020-10-13T14:50:14-575ea5a/darwin-amd64-nocgo
2020-09-18T17:21:06-d91d076/darwin-amd64-10_15
2020-08-16T13:55:00-cf9b4f6/solaris-amd64-oraclerel
2020-06-18T01:14:19-d872bbc/solaris-amd64-oraclerel
2020-05-18T23:04:48-b0bc18d/darwin-amd64-nocgo
2020-05-01T21:57:29-be08e10/darwin-amd64-10_15
2020-04-29T21:29:16-a6deafa/solaris-amd64-oraclerel

[bcmills]

greplogs --dashboard -md -l -e 'FAIL: TestWriteTimeoutFluctuation' --since=2021-01-23

2021-11-18T06:05:29-f6647f2/freebsd-arm-paulzhol
2021-09-24T14:52:47-217507e/netbsd-arm-bsiegert
2021-09-21T20:28:50-2fc7df9/dragonfly-amd64
2021-08-16T21:38:38-c04a32e/darwin-amd64-11_0
2021-03-24T21:19:57-63e9f6d/darwin-amd64-race

[bcmills]

greplogs --dashboard -md -l -e 'FAIL: TestReadTimeoutFluctuation' --since=2021-01-23

2021-11-03T00:07:03-d6f7203/dragonfly-amd64
2021-04-16T01:54:27-f08c552/dragonfly-amd64-5_8

[bcmills]

Part of the problem here, I think, is that the timing check relies on the runtime scheduler rather than the monotonic timer, and relies on the goroutine scheduler rather than comparing times: the timer in the test function that fires at the expected deadline and the deadline computed in the timeoutTransmitter goroutine are completely independent and separated by arbitrary scheduler latency.

It also doesn't help that the test is marked as Parallel, which may substantially increase scheduler noise (especially on small or slow builders). I presume that it is marked as Parallel because it is too slow otherwise, which comes back to the arbitrary timeouts.

I think this test can fairly easily be made both much faster and much more robust.

[gopherbot]

Change https://golang.org/cl/365334 mentions this issue: net: simplify Test*Fluctuation