This test has been disabled as flaky for a while.
While it failed, we were expecting that it was denouncing a valid
problem inside CockroachDB; as it was allegedly reporting “a
performance drop during node restarts”.

However, after carefully looking at the detail of the failures, we
see:

```
QPS of 855.30 ... is below minimum allowable QPS of 900.00; entire
timeseries: [{TimestampNanos:1598976900000000000 Value:29.9}
{TimestampNanos:1598976910000000000 Value:855.3}
{TimestampNanos:1598976920000000000 Value:999.4000000000001} ...  {TimestampNanos:1598977160000000000 Value:996.9000000000001}]
```

The test is failing because the *second* value is below the
threshold. If we look at multiple instances of the failure, the
symptom is always the same: the performance is quite stable *after it
stabilizes at the beginning.* However, it sometime takes more than 10
seconds (1 timeseries data point) to stabilize, whereas the test
expected at most 10 seconds (1 datapoint) of off-threshold
performance.

The problem here is that the QPS increase by the workload program can
actually last for more than a dozen seconds: beyond waiting for the
client to start, the ranges need to spread the traffic, the metric can
lag, etc.

To address this problem in the design of the test, this commit changes
the sequence of checks to *initially* (before the first node restart)
wait for the workload QPS to stabilize, and *only then* restart nodes
gracefully and expect the performance to remain stable.

Release note: None