[PLAT-7848] Improve handling of concurrent crashes

[nickdowell]

Goal

Successfully report crashes in the event that multiple threads crash at the same time.

In the current release, a secondary crash that occurs while the first crash handling thread is still working (and presumably has not yet suspended other threads) will be incorrectly identified as a "crash in the crash reporter" and trigger an internal error report (via a recrash report.)

There are also other race conditions that could cause corruption of the crash reporting process.

Changeset

Crash reporting is now explicitly one-shot (in practical terms it already was - a single crash report path is configured per process lifetime) so that only a single crash report will attempt to be written.

A recrash report is now only written for a secondary crash which occured in the original crash reporting thread.

Both of these checks are performed in bsg_kscrashsentry_beginHandlingCrash() which now takes the offending (crashed) thread as its argument. An atomic compare-exchange operation is used to ensure only a single thread can win the race to be reported.

Crashes in secondary threads are prevented from immediately killing the process by waiting in bsg_kscrashsentry_beginHandlingCrash() until the crash handling has finished.

Testing

An E2E scenario that reliably reproduced the problem has been added, and the fix verified in multiple runs. Attempts to include checks of the stackframe contents failed because C++ exception stacktraces are not currently recorded when Bugsnag is linked dynamically, which it is for the Mac fixture.

Existing test for recrash reports have also been run successfully.

[github-actions]

Infer: No issues found 🎉

OCLint: No issues found 🎉

Bugsnag.framework binary size increased by 984 bytes from 1,299,736 to 1,300,720

Generated by 🚫 Danger