More robust HTTP error handling

[matux]

Description of the change

This PR greatly improves how we handle corner cases and unexpected states when posting occurrences, and how we deal with persistence.

This should take care of all 3 issues listed in this PR.

This is an integral part of the upcoming 1.1.0 version.

Reviewing

• It should be much more expedient to review this on a per-commit basis rather than the whole of it.
• Commits are well-ordered and changes are atomized over specific modules.

CI may fail since it ignores our depency overrides and tries to compile against the library currently published, this is on the to-do list.

Type of change

• [x] Bug fix (non-breaking change that fixes an issue)
• [ ] New feature (non-breaking change that adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Maintenance
• [x] New release

Related issues

• Fixes https://github.com/rollbar/rollbar-flutter/issues/78
• Fixes https://gitter.im/rollbar/SDK-Flutter?at=6361931daa210536d63bde38
• Fixes https://rollbar.zendesk.com/agent/tickets/49527

Checklists

Development

• [x] Lint rules pass locally
• [x] The code changed/added as part of this pull request has been covered with tests
• [x] All tests related to the changed code pass in development

Code review

• [x] This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
• [x] "Ready for review" label attached to the PR and reviewers assigned
• [x] Issue from task tracker has a link to this pull request
• [x] Changes have been reviewed by at least one other engineer

[matux]

@cyrusradfar Agreed, rate limiting is an important next step. I've already thought how to implement it by turning the internal pipeline (from notification to http transport) into a stream of data over time, this is gonna be fun.

Regarding server errors, right now we're handling 429 (Too many requests) and 5xx by suspending transactions for at least 30 seconds which was how it was originally implemented before I came in.

Client errors 413 (Payload Too Large) and 422 (Unprocessable Entity) discard the payload altogether (with a log) to avoid repeatedly sending payloads that may be incorrectly formatted due to a bug.

[cyrusradfar]

Appreciate that, thanks for the response.