Consider custom SIGTERM handler

[jamescrosswell]

Description

.NET runtime no longer provides default SIGTERM signal handler which will affect the AppDomainProcessExitIntegration (the main purpose of which is to flush on exit).

Potentially we could create our own SIGTERM handler to replace this...

Not really sure whether this is a good idea or not. The reason MS are deprecating their handler is:

The SIGTERM signal handler registered by the .NET runtime by default was both insufficient for some app models (for example, console and containerized applications) and incompatible with other app models (for example, Windows services). It's better to leave it to higher-level libraries or application code to register signal handlers appropriate for the given app model.

So maybe we should be leveraging higher levels of abstraction in the various different integrations that we have instead. The docs mention it doesn't work in Windows Services... but we don't have a "Windows Service" integration, so it might not be easy to draw a one to one match between Sentry's integrations and when it would be appropriate to add this hook.

The easy way out as SDK maintainers would be to let SDK users decide if/when they want to enable an AppDomainProcessExitIntegration... however the vast majority of SDK users aren't going to know about or find that option so not sure how effective that will be.

Perhaps there are some clear/obvious situations in which we could enable it but otherwise we leave it "opt in" for SDK users to enable manually for app models where it's unclear to us whether it could/should be enabled or not.

[linear[bot]]

NET-435 Consider custom SIGTERM handler

[Flash0ver]

Depending on the App-Models, e.g. "Generic-Host"-based models, could use Microsoft.Extensions.Hosting.IHostApplicationLifetime's ApplicationStopping or ApplicationStopped tokens.