Insights event batching

[rabidpraxis]

This includes an EventsWorker GenServer.

It bundles up sent events into batches and transmits them to the backend if they hit an event threshold (events_batch_size) or a time threshold (events_timeout). It will drop events if the queue is too full (events_max_queue_size).

This implementation differs a little from our Ruby implementation:

• It attempts to retry batches of events if the server does not respond, or responds with unexpected errors. It drops the batch after n attempts (events_max_batch_retries)
• It can have multiple concurrently retrying batches, but events will be dropped if the max queue size is it (including events already batched)
• It has a static timeout value if the backend responds with a 429. This is an attempt to make sure that we don't send events too often (currently defaulted to 60s) if we know the server will not accept them.

This is ready for a review, but I would like to add a little more testing around the Client.

[stympy]

Looking good!

[rabidpraxis]

Okay the client stuff might need some refactoring after #579 is merged, but the logic and testing around the batching is ready for an actual review.

I updated a few things:

• We log the dropped event count after an interval (hardcoded 60s)
• We now drop batches if we are throttling, so when the backend response with a 429 > events_max_batch_retries times then we toss the oldest batch, with the idea to keep the active set of batches close to the current time.