Feature: Refined Logic for 400 and 429 errors

[kelvin-lu]

Refactor and remove events that should not be retried:

• Payloads that are fully invalid (missingField) are not retried
• Payloads that are invalid with 1 event are not retried
• Payloads that have more metadata on them will remove events:
  • 400 Response Bodies will remove any events specified by eventsWithMissingFields, eventsWithInvalidFields
  • 429 Response Bodies will remove users/devices that exceeded daily limit
• Unit tests for all of the above
  • Refactor MockThrottledTransport -> MockTransport, relocate.

I really wanted to reuse logic between onEventsError and retryOnLoop, but the assumptions each function make (same/different user + device Ids) make it harder.

[kelvin-lu]

@ManThursday we've taken a stab at refactoring retryEventsOnLoop to break out a retryEventsOnce that, as the name says, sends one request and sends as a response flags/arrays that are actionable. Plus refactoring the tests to make more sense (thank you for that suggestion).

One thought I had is to restructure how events are being passed in and out of the retry buffer - right now, the retry function creates a slice of the main retry buffer each time I try to send the events and using eventCount to keep track of how many events I should try.

I thought I could refactor this to instead splice all the events at the beginning of retryEventsOnLoop and unshift them back in every time the payload gets cut. it might be simpler and reduces concerns of what happens if retryEventsOnLoop manages to get called on the same device + userID, but adds a new concern would be the performance of unshift (which may or may not be a real concern) - thoughts? I wouldn't try to tackle this in this PR, but wanted to throw out the idea