Sentry should raise an exception if the DSN has not been configured

[jamescrosswell]

Problem Statement

At the moment, if the DSN is empty, you get a DisabledHub. But that's because we've decided to use "" as the DSN for a disabled hub.

This means the SentrySDK is unable to tell if someone forgot to supply the DSN or if they intentionally left it blank in order to disable Sentry.

Solution Brainstorm

If the DisableSdkDsnValue was a non-empty string (e.g. "disabled") then people could still disable Sentry via code/config. and we could then provide some useful guidance when initialising the SDK in cases where they forgot to supply the DSN (e.g. "Error: You forgot to supply a DSN. Sentry needs a DSN to do anything useful.").

This is a breaking change, so would need to wait until the next major release.

Additional comments from Kanadaj

@jamescrosswell I just want to highlight the fact that dsn is an optional argument of WriteTo.Sentry():

sentry-dotnet/src/Sentry.Serilog/SentrySinkExtensions.cs

Line 86 in 0ea0f0a

string? dsn = null,

So supplying the dsn is required, but the dsn argument is not? It's kind of super confusing as a user of the library, especially since the Serilog provider doesn't seem to read the value from IConfiguration unlike UseSentry().

I guess a solution would be to have 2 alternative calls with WriteTo.Sentry(), one that takes a non-null string as the first argument, and one that takes a boolean for initializeSdk as the first non-optional argument.

Originally posted by @kanadaj in #2883 (comment)

[bruno-garcia]

This "" behavior is 10 years old and set in all SDks. Not sure this is worth doing. Usualy not passing the DSN means null is passed (DSN should be nullable). And in this case, throwing would be OK.