Add Send Failure Callback API

[naftaly]

Despite the newer features designed to limit report sizes, reports can still occasionally exceed the limit, resulting in them being silently deleted without being sent. When this happens frequently, there’s no way to detect it, which can lead to ticket prioritization problems and potential business losses.

This PR introduces a new callback, onSendFailureBlock, which is triggered when a report is dropped by the system without this being the intention of the sender.

I understand that Bugsnag typically doesn’t accept new features via PRs, but this one is straightforward and could provide significant value to end users. I’d greatly appreciate it if you could consider merging it as is or making any necessary adjustments before merging.

Thank you!

[tomlongridge]

@naftaly – thanks for the PR.

Post-delivery callbacks are something we are considering including in our SDKs, but we'd want to implement an API that allows for both successful and unsuccessful outcomes. Having discussed this in the development team, we're more keen on advancing the payload trimming logic to near-eliminate the possibility that the payload would fail in the first place. This would benefit all users and not require a secondary reporting mechanism to be notified of the event.

We have a few ideas that we think would allow us to achieve this without jeopardising the quality of stacktrace. We hope to action this reasonably soon and will keep you updated.

[naftaly]

@tomlongridge I'd be happy to update this PR to include callbacks for successful deliveries as well. I believe having high-level visibility into what is being sent (or not) is crucial for a system we rely on, like Bugsnag.

As for trimming data, I feel it's a decision best left to the sender, as business needs can vary and dictate different rules. While the existing adjustment options are quite helpful, trimming may not always be the ideal approach.