Cleanup initialize/close behavior to prevent initialized? checks everywhere

[sl0thentr0py]

And perhaps we should implement a better version of close and Sentry.initialize? 🤔

Specifically:

• We don't erase hub variables, @background_worker and @session_flusher
• Sentry.initialize? is backed by a simple boolean state that's changed by Sentry.ini and Sentry.close.

We would still need Sentry.initialize? in some places to stop some actions after the SDK is closed, but we don't need it for preventingnil value anymore, which is getting out of hand IMO.

Originally posted by @st0012 in #2084 (comment)

[st0012]

The eventual goal is to find a way to limit the number of Sentry.initialized? check, so I went back to related issues:

• Threading exception with Resque/Redis in exit #2054
• Using guard to run integration tests results in undefined method `set_transaction_name' for nil:NilClass #1885
• undefined method `exclude_loggers' for nil:NilClass during Rails boot on production #1858

And just having this change wouldn't reduce any of those checks as we usually do Sentry.foo.bar, where as long as Sentry.foo returns nil, we'd still see the same error.

So to actually achieve the goal, we need to ensure the data flow is not interrupted after Sentry.close and just block event-sending:

• Return nil if the SDK is not initialized at all
• Perform the action if the SDK is initialized
• Perform the action if the SDK is closed
  • In this case, Client should block the event sending

It'd avoid all the Sentry.initialized? checks added above issues because they're already behind other initialization checks.