feat: Added SessionEndStatus.Unhandled

[bitsandfoxes]

Relates to #4632

Problem

The SDK should use the new SessionEndStatus.Unhandled when capturing an unhandled exception that does not cause the application to crash.

Unhandled exceptions typically lead to a terminal state of the application. The only exception (hehe) to this was the UnobservedTaskExceptionIntegration. Another instance where this is highly relevant is Unity: Unhandled exceptions get "swallowed" by the engine and the game just continues.

Context

Within the Sentry SDK for .NET the only non-terminal unhandled exception comes from the UnobservedTaskExceptionIntegration that also gets special cased in SentryEvent.HasTerminalException() where we compare against the mechanism key

sentry-dotnet/src/Sentry/SentryEvent.cs

Lines 188 to 191 in 04c932b

	if (Exception?.Data[Mechanism.HandledKey] is false)
	{
	return Exception.Data[Mechanism.MechanismKey] as string != UnobservedTaskExceptionIntegration.MechanismKey;
	}

This is limiting as it does not allow for other integrations i.e. coming from the Unity SDK to add to this check.

Proposal

Option 1: Add list of NonTerminalMechanismKey on the options

One straight forward solution to this would be to have an internal List<string>? NonTerminalMechanismKeys; on
the options and have integrations add to the list during their registration. We'd need to pass the options into the HasTerminalException check but they are available everywhere we'd need them.

There are a couple of downsides to this:

1. Should the list be internal or public. If we keep it internal the Unity SDK can add to it but no user written integration can.
2. We're polluting the options with one more list of things.
3. It's just a bunch of string comparisons that make this work

Option 2: Rework the Mechanism bool? Handled to an explicit enum ExceptionHandledState

The Terminal state is only ever relevant in case of an Unhandled Exception. This makes the additional property somewhat redundant. An alternative solution would be to replace the bool? Handled with an explicit ExceptionHandledState. This would be quite the breaking change and we'd need to take special care during serialization.

public enum ExceptionHandledState
{
    /// <summary>Exception was never thrown (constructed and captured)</summary>
    NotThrown,

    /// <summary>Exception was caught by user code</summary>
    Handled,

    /// <summary>Unhandled exception that causes application termination</summary>
    UnhandledTerminal,

    /// <summary>Unhandled exception that doesn't cause termination (e.g., UnobservedTask, Unity)</summary>
    UnhandledNonTerminal
}

public ExceptionHandledState? HandledState { get; set; }

Option 3: Extend Mechanism to have a bool? Terminal property

The mechanism on the exception already has things like Handled and Synthetic. We can extend this by adding bool? Terminal. Integrations that capture unhandled non-terminal exceptions can set the Terminal state to false and we can check for this on the SentryEvent. We keep it on the top-level of Mechanism but we don't need to serialize it so it won't get sent to Sentry.

This sounds to me the most pragmatic and minimal invasive change. The only downside I can see right now is that the property is only ever going to be useful when Handled is false. But we can keep it nullable.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against a1500c3

[codecov]

Codecov Report

❌ Patch coverage is 94.44444% with 2 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (version6@382fa2e). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
src/Sentry/SentryEvent.cs	86.66%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             version6    #4633   +/-   ##
===========================================
  Coverage            ?   72.97%           
===========================================
  Files               ?      480           
  Lines               ?    17378           
  Branches            ?     3431           
===========================================
  Hits                ?    12681           
  Misses              ?     3840           
  Partials            ?      857           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bitsandfoxes]

This is really annoying.. running ./build.sh on a beefed up m3

Build failed with 13 error(s) and 4 warning(s) in 1444.0s

because

Could not find android.jar for API level 36. This means the Android SDK platform for API level 36 is not installed; 
it was expected to be in `/Users/bitfox/Library/Android/sdk/platforms/android-36/android.jar`.

and all I want to do is to please Verify...

[bruno-garcia]

while talking through this a bigger problem has been uncovered, with restarting sessions on unhandled

[bruno-garcia]

@bitsandfoxes CI is all broken

[bruno-garcia]

@sentry review