Support setting error type on individual stack frames

[fractalwrench]

Goal

Supports setting the error type on individual stackframes by setting the Bugsnag-Stacktrace-Types header. This allows the pipeline to distinguish events and process them accordingly. Supported values are android, c, reactnativejs. These are set as a comma delimited string.

Changeset

• Updated errorApiHeaders() to set Bugsnag-Stacktrace-Types header if the value has been set
• Calculated value of Bugsnag-Stacktrace-Types from the event (by checking all the types set on every stackframe) and from the file (by checking encoded info in the filename)
• Updated EventStore to encode the error types in the event file
• The AnrPlugin now updates the thread.0.stacktrace when capturing an error - previously only errors.0.stacktrace was updated, which lead to a disparity in information on the dashboard
• Created EventFilenameInfo file which holds classes/functions responsible for encoding/decoding event information into an Event

Testing

• Added unit tests to verify error API headers, the error type calculation, and the event store filename
• Updated existing stackframe serialization tests to verify type is serialized
• Enhanced existing E2E scenarios to include checks on type field
• Verified that ANRs set their error type accordingly via E2E scenarios

[bugsnagbot]

Android notifier sizes

Format	Size impact of Bugsnag (kB)	Size impact of Bugsnag when Minified (kB)
APK	1447.49	1364.77
arm64_v8a	373.35	291.43
armeabi	352.86	266.85
armeabi_v7a	336.49	250.46
x86	414.29	328.28
x86_64	393.82	311.9

Generated by 🚫 Danger

[tomlongridge]

The API spec, and the intent of the change, is for the field says that the frame type should be set where it doesn't match the error type. I don't think we should be setting the type for all NDK frames - only when it's been set explicitly either in a callback or by one of the new features.

[fractalwrench]

Updated changeset so that the type is only set on individual stackframes when the error object is mixed (as with native ANRs). E2E scenarios have also been added to verify this.

This should be ready for another round of review, pending the results of CI.

[tomlongridge]

Looks much cleaner 👍 I've made some suggestions from the point-of-view of someone reading this for the first time, to make the abstraction cleaner.