metabug: problems from check-fast being sole test driver

[pnkfelix]

On Windows, since process spawning is very slow, we use the strategy of combining a (large) subset of the tests into one program, and then compiling that once and running it.

This strategy has some drawbacks/weaknesses, and has introduced some problems.

This metabug is a place to relate those issues. The intention is to collect problems that arise from the check-fast target itself; that is, problems that would affect any use of check-fast as a sole test driver for a target (as opposed to problems that would affect Windows alone; i.e. if we were to port to some a new target platform that also only used check-fast as its test target).

[pnkfelix]

See also #4193

[pnkfelix]

Note also that Sully's suggestion from #8456 makes an interesting suggestion of running check-fast followed by tests marked xfail-fast to increase the coverage over just running check-fast alone, which might help with some problems related to this.

[sanxiyn]

check-fast may also be useful for Android, since running a test involves spawning adb, adb copying the test binary to the remote device, spawning adb again, and adb talking to the remote device to spawn the copied test binary, or something like that.

[vadimcn]

Windows may be not entirely at fault for slow process spawning: #8859