Consider NOT sending debug images in certain cases

[mattjohnsonpint]

Problem Statement

The DebugImage class was originally added in version 3.16.0 with #1513, but was unused until we added Portable PDB support in version 3.25.0 with #2050.

Since 3.25.0, we've been attaching SentryEvent.DebugImages and sending them to with Sentry events, on the debug_meta.images interface. We do this for almost every error event, as long as we can determine a debug_id. This is a signal to Sentry that symbolication should be attempted when the event is processed. If matching debug information files (symbols and/or source bundles) are found, then everything works fine and as intended.

The problem is that currently, if debug_meta is sent, and no matching debug file was uploaded, it can result in errors displayed in the Sentry UI such as:

These are noise for .NET developers in cases where symbolication is already happening client-side and source context isn't desired.

Solution Brainstorm

We could try to detect if SentryUploadSymbols or SentryUploadSources were both unset, write that as an attribute on the assembly, then use it at runtime to avoid sending debug images.

Alternatively, we could just continue to let debug images to always be sent. The error messages can be suppressed on the server side.

[mattjohnsonpint]

The errors have been suppressed with getsentry/sentry#45571. Once deployed, the errors will only appear in older versions of Sentry. So my opinion is to let this be.

[mattjohnsonpint]

Another approach would be to allow an SDK option to control this. Something like SentryOptions.SendDebugMeta, true by default, but can set false for those that want to avoid this scenario.

[mattjohnsonpint]

I've been thinking this through more, and I think we should just always send the debug image info if we can. Reason being is that the debug_id is essential to be able to correlate any PDB or source code from any location.

Let's say for example that you publish symbols to a symbol server, so you don't upload them to Sentry. We will still need the debug_id to find those symbols. Perhaps you're also using SourceLink. When getsentry/symbolicator#1034 is completed, we will be able to support using that to derive source context. But not if we don't have the debug_id.

Also, most applications have several different assemblies, including the application itself, any libraries it uses, and the framework and runtime assemblies that come with .NET. Each one would have its own debug_id, and resolve symbols and sources separately.

Thus a global setting like SendDebugMeta = false would disable all symbolication and source context - not just that associated with the final application.

Better to just keep sending the debug info when we have it, and deal with any UX errors on the server side.