Add DogStatsD extended aggregation support

[GrgDev]

This PR aims to add the ability for statsd exporter to receive DogStatsD extended aggregation metrics. It is a feature I requested in Issue #557 and I wanted to try to implement it myself following the in-issue commented advice from @glightfoot.

Summary of Implementation

When DogStatsD has extended aggregation enabled, instead of sending:

my_distribution_metric:21|d|#all,my,tags
my_distribution_metric:43.2|d|#all,my,tags
my_distribution_metric:1657|d|#all,my,tags

it sends

my_distribution_metric:21:43.2:1657|d|#all,my,tags

This PR updates the LineToEvents function in the specific case of more than one : left of the initial |. If so, assume it is an extended aggregation line, convert it back into its multi-line non-aggregated form, then pass it onto the rest of the function as the samples. The logic enforces that this form of aggregation metrics must be only of the types of distribution, histogram, or timing.

[glightfoot]

It might be good to add tests with metrics without tags as well, invalid tests where someone submits a line with a different tagging style (e.g. SignalFX) and the dogstatsd extended aggregation, and invalid tests for extended aggregation with counters and gauges

[GrgDev]

I believe I have now added these tests plus some extras as well as the additional logic required in the line.go code to pass them.

One more question. If parsing for DogStatsD tags is disabled, should a line with the extended aggregation format result in:

1. no tags but otherwise the same output as if DogStatsD parsing was enabled
2. no output as the line is considered a bad line
   ?

The other tests seemed to suggest that the main side effect of turning off parsing should be no tags, but since this is a DogStatsD specific feature, should an extended aggregation line be considered invalid altogether in such a scenario?

My opinion would be that option 1 is what we should go with because the current code base suggests that the parsing flavor options only affects the tag parsing and no other part of the line. Also, as the tests show, it already enforces that extended aggregation cannot be used with other flavors of StatsD.

[GrgDev]

@glightfoot Friendly nudge

[matthiasr]

Thank you for your contribution, and thank you @glightfoot for the initial review as well!

[matthiasr]

I'll accept this as is, but this amount of string manipulation is making me nervous – both for the potential to mess up a line, and because of the amount of intermediate strings we're leaving for the garbage collector to deal with.

I would prefer if we could delay dealing with the multiple samples in a line until line 280, when we turn the value into a float. There, we could turn the single value float64 into a values []float64, looping over the : separated values to parse them in turn. We should be able to do this without allocating any additional strings. Then, further down on line 331, where we're emitting 1/samplingFactor events, we could also loop over that.

That being said, I've left this PR hanging for too long, so I'll take working over perfect. If anyone runs into actual issues from the current approach, or feels otherwise motivated, maybe this comment can help guide them 😃

[m-barthelemy]

After updating to 0.27.1, this line is triggering a panic: runtime error: index out of range [1] with length 1 for us.