Enhance available threshold values for Rate, Gauge and Trend metrics

[na--]

A k6 Rate metric, either custom or predefined (e.g. checks), consists of just 2 counters, Trues and Total, and the rate we expose to be used in threshold definitions is just the first counter divided by the second. This is all well and good, however, there are valid use cases for also being able to access (and define thresholds based on) the underlying counters as well. Even the derived value of Total-Trues (i.e. falses or failures or whatever we decide to call it) might be useful in a lot of use cases...

For example, say that you want to track failed HTTP requests (#1311), it might make sense to want to be notified if either the HTTP failure rate exceeds 1%, or if we have more than 500 failed requests. You don't really know the precise number of requests your script is going to make, but either of these conditions may seem worth investigating, so you'd want your CI to fail it they happen or something like that. Of course, you can even now, but it's going to needlessly require an additional custom Counter, which is both poor UX, and more inefficient to compute...

Implementation-wise, this should be very easy to add to k6, even with the current somewhat ad-hoc threshold implementation (#961). We just need to synchronize with the cloud execution, so it's supported there as well. It will also likely be even more useful when we have sliding windows for thresholds (#1136)...

[na--]

Just saw that we don't expose the count value of Trend metrics in thresholds as well... We keep it, and we even recently allowed it to be displayed in the end-of-test summary report (#1143), so I see no reason we shouldn't be able to reference it in a threshold definition...

[na--]

Turns out we also don't expose the min and max values of a Gauge metric 😞

k6/metrics/sink.go

Line 48 in a2ab89a

Max, Min float64