x/build: increase timeouts or reduce parallelism on darwin-arm-mg912baios builder?

[bcmills]

There is a strange effect visible in this log on the darwin-arm-mg912baios builder.

The tests are running along fine for a while, and when they get to the (presumably CPU-intensive) hash/* tests they suddenly dropm from ~150s per test to ~19m per test.

The first couple of image tests are similarly slow, but then the builder seems to recover:

ok  	go/parser	89.266s
ok  	go/printer	93.493s
ok  	go/scanner	90.741s
ok  	go/token	91.229s
ok  	go/types	93.029s
ok  	hash	95.535s
lldb: running program
PASS
*** Test killed: ran too long (19m0s).
FAIL	hash/adler32	1145.074s
ok  	hash/crc32	1140.671s
ok  	hash/crc64	1139.541s
ok  	hash/fnv	1137.713s
ok  	html	1136.359s
ok  	html/template	1135.509s
ok  	image	1133.465s
ok  	image/color	1135.193s
ok  	image/draw	91.719s
ok  	image/gif	95.854s
ok  	image/jpeg	102.705s
ok  	image/png	102.427s

I wonder if that implies some sort of resource contention (perhaps a thermal limit?) between the tests — should we reduce the parallelism of that builder to decrease the likelihood of spurious timeouts?

CC @eliasnaur @steeve @bradfitz @dmitshur

[eliasnaur]

Now we have a virtual corellium darwin/arm64 builder, the two iOS device builders could be retired. It means that we'll lose darwin/arm coverage, however. It's up to @steeve who runs the device builders and has a very popular gomobile app deployed.

[steeve]

I think reducing the parallelism is super fine.

We are looking into deprecating darwin/arm ourselves, although we are not there just yet. Most likely target is september with the release of iOS 13, which means we may be able to deprecate iOS 10, and arm32 with it. That said, we don't need the per-commit granularity, so it's completely fine if it runs like once a day or something, so that we don't discover something is wrong at release time.