Performance refactor of running_output buffers

[sparrc]

this is a WIP, todo:

• Unit test ordering sanity in running_output_test.go
• Write unit tests for buffer.go
• Determine best way to log metric drops
• Track internal buffer metrics, and log occasionally

benchmarks are looking good so far, ~1.8x faster performance on Add & Write:

this PR:

% go test ./internal/models/... -bench=. -run=Benchmark
PASS
BenchmarkRunningOutputAddWrite-4            10000000           222 ns/op

same benchmark on master:

% go test ./internal/models/... -bench=. -run=Benchmark
PASS
BenchmarkRunningOutputAddWrite-4     5000000           395 ns/op

[sparrc]

@PierreF Could you review these changes?

externally the usage of running_output is the same as the changes you made, but I've changed it to utilize a circular buffer using channels. This not only reduces the processing time (no locks are required), but it also reduces allocations, as slices only need to be allocated when a user requests a batch to be written.

[PierreF]

I didn't got any issues with this PR, I'm using it since this morning (UTC+2 here). Metrics were always ordered and capacity matched configuration.

The most strange thing I got was "buffer fullness: 1083 / 1000 metrics". Since in fact it could buffered up to metric_batch_size + metric_buffer_limit. But i'm don't think it worth changing anything.

[sparrc]

@PierreF yes, that was by design, I think it makes it more clear that we are currently over the buffer limit, and if a write fails then there will be dropped metrics.

I originally set the denominator to be MetricBufferLimit + MetricBatchSize, but I felt that was even more alarming, because then metrics could be dropping even though it appeared that the buffer was not full.