go: runtime: frequent timeouts in {build,runBuilt,run}TestProg

A much simpler thing we could do is to increase the timeout for the runtime test. We already do this for the cmd/go tests [1] and I don’t think that’s any more artificial than factoring the cgo prog tests out into their own test.

[1] Or, at least, we try to. The code is weird.

Perhaps some of these slower tests should be skipped in short mode?

Since we don’t have a long builder for these, this seems like it would lose important test coverage.

or perhaps move some of the slower ones out to some package that won’t also be run by users as part of go test all in their own modules.

This seems feasible. As you pointed out, this would give it its own timeout. It would require some nontrivial refactoring to pull out the testprog infrastructure, but we could do that.

On a Solaris system I have access to, clearing the cache and running go test -test.short -test.v -test.count=1 runtime takes 38.5 seconds. The last two tests to complete are TestCgoExternalThreadSIGPROF and TestCgoExternalThreadSignal which both take about 13 seconds. One test is building the test program, and the other is waiting for that build to complete (they both build the same test program). Actually running the test program takes a fraction of a second.

This is consistent with the builder failure just being slow and running out of time, especially since cmd/dist will be running other tests in parallel.

In the 2021-11-22 timeout the only tests still running are two waiting for go build -tags=threadprof testprogcgo to complete.

After CL 364654 the time required to run the runtime tests on a Solaris system I have access to drops from 70 seconds to 51 seconds. CL 364755, if submitted, will drop it farther. I don’t know if timeouts are the problem here, but they may be part of it. But there may also be a different problem.