Set Scope.User.Id to the InstallationId by default

[jamescrosswell]

Resolves #3302

[bitsandfoxes]

I think this is doing it the wrong way around. Now the client and the session manager each hold their own version of an installationIdHelper. And the client tries to fix a missing ID after the fact?

The ID is part of the state and should sit on the hub if it's getting used in multiple places, which, if it's getting resolved in the GlobalSessionManager, is already sort of happening. In that case, it should be set on the user where applicable.
The client should not need go around trying to cover gaps in the setup.

[jamescrosswell]

I think this is doing it the wrong way around. Now the client and the session manager each hold their own version of an installationIdHelper. And the client tries to fix a missing ID after the fact?

The ID is part of the state and should sit on the hub if it's getting used in multiple places, which, if it's getting resolved in the GlobalSessionManager, is already sort of happening. In that case, it should be set on the user where applicable. The client should not need go around trying to cover gaps in the setup.

That sounds good in principal. In practice, I had to delay setting the User.Id until the client since setting it earlier impacts various other functionality.

Here, for example, the client runs an enricher:

sentry-dotnet/src/Sentry/SentryClient.cs

Line 147 in c541459

_enricher.Apply(transaction);

The enricher does this:

sentry-dotnet/src/Sentry/Internal/Enricher.cs

Lines 79 to 82 in 5bcb9ca

	if (_options is { SendDefaultPii: true, IsEnvironmentUser: true } && !eventLike.HasUser())
	{
	eventLike.User.Username = Environment.UserName;
	}

Setting the User.Id before this point would break the enricher then (as it changes the result of the call to eventLike.HasUser().

The MainSentryEventProcessor does something similar for events.

I think utlimately the InstallationId is not state that's held by the hub at all... rather it's state that gets initialised the first time the SDK runs for a particular project on a particular device. It sets a unique ID identifying that installation and stores it on the file system. Logically, it's a piece of context that stays the same for the duration of the application's execution so it's similar to some of the other stuff we new up when initialising the SDK/Options. It's accessed by the Global Session Manager and also by the Sentry Client - but neither of these creates/owns/stores that state. I'm thinking maybe we could move it to be a Lazy property on the SentryOptions then (SentryOptions.InstallationId). That seems like a more natural place for it to live.

[bitsandfoxes]

Ahh, I like this a lot better! That makes a lot of sense, putting it on the options! Thanks for that!