feat: add GetSampleRateMulti

[kentquirk]

Which problem is this PR solving?

This library was designed to count spans and to sample based on the assumption that every span processed would get an independent sample rate. But that's not how it's being used by Refinery -- Refinery does its calculations based on traces, so each call to GetSampleRate is likely representative of multiple spans.

Short description of the changes

• Add GetSampleRateMulti, which takes a count of the number of events that it references, to the Sampler interface
• Implement GetSampleRate for all samplers in terms of GetSampleRateMulti()
• Add Stop to the Sampler interface for halting samplers safely
• Add an EMA test
• Add a generic sampler test that only uses the public interface including Stop

[TylerHelmuth]

A lot of these changes look like they were in #54, did something strange happen with a rebase?

[cartermp]

Refinery does its calculations based on traces, so each call to GetSampleRate is likely representative of multiple spans.

Could you describe an example of how this can help people using Refinery? I...think I get it, but I'm honestly not sure! Would this mean that sample rates are incorrectly reported or inflated today?

[kentquirk]

Sample rates in refinery are calculated by asking the samplers to make their calculations once per trace. But there are a variable number of spans per trace, and Honeycomb bills by the span. So when we're sampling to limit throughput, we should be calculating these numbers based on the number of spans in the trace.

When we're sampling based on keeping a distribution of keys, we could do it either based on spans or traces. It's not likely to make a difference unless span length is correlated to key value (possible, but probably not common).

For the EMAThroughput sampler I'm currently working on, controlling throughput while still seeing representative data is the primary goal, so it will definitely be looking at span count.