Atomic based limiter

[storozhukBM]

Hi,
I've made your limiter implementation atomic based. It is a little bit harder but in generally faster and has no goroutine scalability issues that any mutex based implementation have.
Checkout this relation between RateLimiter latency and count of goroutines:

Original implementation moved to mutexbased.go file, so you can run benchmarks and play with other tests. But I'd suggest to leave only one implementation after all.

[Side note] This wired latency spike in mutex based implementation is a direct illustration of mutex falling into starvation mode.

Full benchmarking results here

[CLAassistant]

All committers have signed the CLA.

[storozhukBM]

Hi @kriskowal,
Sorry for bothering you, but maybe you'll have some time to look at this changes.

[siennathesane]

@kriskowal any thoughts here?

[kriskowal]

This looks like a pretty fantastic change. Can you move the prior implementation into an internal package so we don’t grow the API surface?

Sorry for the extraordinary delay.

[storozhukBM]

Hi @kriskowal
There was no easy way to move mutexLimiter into internal package because it depends on some types from ratelimit package like Clock, Limiter, Option...
So I decided to make newMutexBased private, which is basically has the same results, and we don’t grow the API surface.

[kriskowal]

Looks good. I’ll try to land, changelog, release this week.

[peakle]

@storozhukBM where did you create this awesome benchmark visualization?

[storozhukBM]

@peakle
Exported benchmark results to csv and configured graph in Numbers(spreadsheets software that goes together with MacOS)