End of test information in collector

[martinfijal]

We'd like to have access to more information in the collector when a test finishes. Specifically:

1. Start and end timestamps for the test to make sure we use the same everywhere.
2. Final threshold information including the name, limit and calculated value. Needed for the UI to be able to present whether this threshold failed or not.

[liclac]

1. You can use the time Run() was called, and when the context expired.
2. I'm not sure if this will be very useful, since the idea is that for the cloud service, we'll run thresholds externally from k6? A k6 instance can only run thresholds on its own values, so if we have several of them evaluating their own samples, we may get inconsistent results.

[martinfijal]

1. I was curious if there was an "official" time that will be the same for all types of output. Getting the time in Run() is what I'm currently doing. Not really needed, I was more curious if something like this existed already.
2. When k6 is run locally with results streamed to the cloud we'll use the threshold information from k6.
   When tests are run in the cloud it need to solved in some other way.

[liclac]

Oh, I just remembered, you can just check sample.Metric.Tainted. If m.Tainted.Valid is false, it means it either has no thresholds, or they haven't run yet, otherwise a true value means its current state is failing (it may recover).

We need to solve this for distributed execution (#140) somehow, but we can think about it later. I have a couple of ideas, ranging from querying the backend to writing metric information to the cluster's datastore.

[martinfijal]

Ok, but this way I need to do a lot of bookkeeping to figure out what is tainted or not in the end. And this is also only gives me access to the boolean part of the threshold. Frontend is also in need of presenting the value and the level for the threshold (preferably without having to parse the threshold expression). That is why I'd like the engine to compile together this information about the threshold at the end of the test and sent to collectors.

[liclac]

I'll have to think about how to do this, the code surrounding thresholds is somewhat messy and needs some cleaning before it can be exposed to anything

[martinfijal]

Also sample.Metric.Tainted isn't saying anything about which threshold expression triggered if I have specified multiple ones.

[liclac]

I think what we need here is to rework the Metric struct a bit; thresholds, submetrics and the sink should be available within it.

[liclac]

Working on this right now.

[liclac]

You can now access thresholds from Metric objects, working on getting derived metrics in there too…