runtime/pprof: testCPUProfile hides real issues

[aclements]

In response to #7095, we made the profiling tests pass if they get at least one sample. This is masking real issues. For example, on ARM, TestStackBarrierProfiling usually gets fewer than 10 samples, when it should be getting around 500 (discovered in #13405). It would be better if, when this got fewer samples than expected, it simply retried the test a few times. This would keep the test fast under common circumstances while still keeping it robust. (This is technically a repeated fixed-horizon hypothesis test, which technically means it's bad. What we really want is a sequential hypothesis test, but as long as the difference between "working" and "broken" [effect size] we're looking for is large enough, the simple thing is fine.)

@randall77 @RLH @dvyukov

[aclements]

I'm sure this is going to turn up issues that are best dealt with by keeping an eye on the builders, so I've moved it to 1.7Early. It's also likely there are going to be issues we simply can't fix in the less used platforms because of kernel problems.

[bradfitz]

We still have a few months to watch builders if you want to do this now-ish. Otherwise feel free to kick it down the road more.

[aclements]

As of commit 7037c15, we started checking that we get at least 25% of the expected number of samples. That's been in for a while and seems to be working fine.