Improve SDK Initialization

[bitsandfoxes]

trafficstars

The Problem

Currently there are multiple ways to initialize the SDK, none of them ideal. There are multiple Init methods while the SDK is auto-initializing. Users have no straight forward way to control or delay initialization.

Context

There are multiple ways to initialize the SDK.

SentrySdk.Init()

This is the entry point into the .NET SDK. It is discoverable and callable from anywhere inside the Unity project. The SDK calls this as part of SentryUnity.Init.

SentryUnity.Init()

This is the entry point into the Unity SDK. https://github.com/getsentry/sentry-unity/blob/14882b7b53636e05ce995c8d7ba20c68d0a90f2e/src/Sentry.Unity/SentryUnity.cs#L31 The SDK is also using it as part of the auto-initialization through SentryInitialization

SentryInitialization.cs

The SDK provides a SentryInitialization.cs as .cs script so it has access to precompiler directives and other, targeted platform specifics like IL2CPP methods https://github.com/getsentry/sentry-unity/blob/14882b7b53636e05ce995c8d7ba20c68d0a90f2e/package-dev/Runtime/SentryInitialization.cs#L54-L56

Due to the RuntimeInitializeOnLoadMethod there's currently no way around the SDK attempting to auto-initialize. The flow is

1. The options get loaded from /Resources
2. The ConfigureCallback gets invoked, allowing user code to get executed https://github.com/getsentry/sentry-unity/blob/14882b7b53636e05ce995c8d7ba20c68d0a90f2e/package-dev/Runtime/SentryInitialization.cs#L60
3. Native SDKs get setup/initialized (scope observer, background worker setup, e.t.c)
4. https://github.com/getsentry/sentry-unity/blob/14882b7b53636e05ce995c8d7ba20c68d0a90f2e/package-dev/Runtime/SentryInitialization.cs#L88-L96
5. The SDK calls Init https://github.com/getsentry/sentry-unity/blob/14882b7b53636e05ce995c8d7ba20c68d0a90f2e/package-dev/Runtime/SentryInitialization.cs#L69

Proposal

Changes

1. Unify all Init into one class SentryUnity.
2. Hide .NET SDK init - we do have access to the source due to submodule. We can hide it, or have it partial?
3. Have one Init method with the RuntimeInitializeOnLoadMethod that checks for option.Enabled and bails early. It calls 4. otherwise
4. Have a public Init method that gets called by 4. that also does the native-sdk configuration. Add/keep appropriate overloads.
5. Put UnityInfo somewhere accessible (i.e. the options, or have it on SentryUnity and have the options fetch it from there).

User flow

Automatic Initialization

Nothing changes. The runtime attribute still initializes the SDK. The configure callback still gets invoked, allowing users to make programmatic changes to the options without having to worry/care about initialization timing.

Programmatic Initialization

For users that want to delay or manually initialize they'd disable the SDK in the config window. The auto-initialization will bail early. At any point, they can then call SentryUnity.Init and the SDK will correctly handle native-sdk initialization and platform restriction.