Fix empty or null DSN not disabling Sentry

[ste93cry]

Fixes #453. During the refactoring of the Configuration class of the bundle, for some reason I thought that when the DSN value is an empty string or a null value it should have been removed from the options array, probably because I forgot that the default value in the base SDK is the SENTRY_SDK environment variable and not a null value. This causes a big problem when you explicitly set the option to one of those values (for example in the test or development environment) and the environment variable is also set because the option is not passed to the core SDK and Sentry remains enabled.

[Jean85]

Is there any way to test this?

[ste93cry]

Technically speaking yes, we could add a test that assert that given a certain value of the DSN option it is kept, practically I don't see any value in doing it because there is no code to test

[Jean85]

That's still a regression test. It's a test of a functionality, the fact that you had to delete code to make it work doesn't make the bug disappear out of thin air.

[ste93cry]

The point is that as I already said there is nothing to test: the fact that a value (regardless of what is it) set for the DSN option is passed down to the Options object is already handled here, and since there isn't anymore the code that treats the null value differently, the existing test method should inherirently also test this case

[Jean85]

That's not the full picture.

Here you have a side effect from the client hijacking the bundle's configuration. I would imagine a test where I set the SENTRY_DSN env variable, set null in the bundle and expect null in the options. That test would fail on master now, but be green in this PR.

[ste93cry]

I set the SENTRY_DSN env variable, set null in the bundle and expect null in the options

Once we test that whatever value is set in the bundle's config is also set in the options of the client, we test everything we should in this package. In turn, it's the job of the tests in the sentry-php package to ensure that if no explicit value is given, the environment variable first and null then is used as fallback. Since what was happening before is that we were manipulating the bundle config before passing it to the client to drop the option entirely (consequently falling into the test case mentioned before), it's normal that there was a test for this. Now that this doesn't happen anymore there is nothing more to test. Does it makes more sense to you now?

[Jean85]

Ok I'm fine with it, let's ship it