Avoid user data directory pollution by Sentry

[dengr1065]

osu! relies on Sentry for logging exceptions, and I'm fine with this. However, by default the Sentry SDK for .NET creates a directory at %localappdata%\Sentry on Windows and $XDG_DATA_HOME/Sentry on Linux to store the unique installation ID. As a user who often needs to access application data directories, these useless directories annoy me. osu!(lazer) already has its own storage directory in these user directories (even if changed by the user), therefore Sentry data should be stored there as well.

Searching for simple ways to change the directory path didn't yield any useful results, so I cloned the repository and found that CacheDirectoryPath option is used for installation ID as well (see InstallationIdHelper.cs, lines 58-60). Of course, setting this directory also enables payload caching, though that may be a good thing.

Alternative considered: set DisableFileWrite. I don't think this is what you want, as that would make logging worse.

I have tested this approach by modifying osu.Game/Utils/SentryLogger.cs to initialize Sentry SDK in development context, then adding options.CacheDirectoryPath = "/tmp/";. A file was correctly created at /tmp/sentry/Sentry/9475B066A726B774C66441A00B887CE9CF16E1AA/.installation.

This is a minor issue for me, but I'd still like to see the behavior changed. Unfortunately, I'm not able to do a proper contribution for this as I'm not sure what would be the proper way to access the osu! storage directory in the context of SentryLogger.

[peppy]

Please give #31417 a try.

[dengr1065]

Thank you for looking into this. With this PR the Sentry directory is created inside osu-development as expected, and ~/.local/share/Sentry is not created anymore ✅

I have also intentionally triggered a hard crash by spamming block/compact Realm buttons, a file was created in osu-development/Sentry/9475B066A726B774C66441A00B887CE9CF16E1AA/__processing and got deleted on next game launch. Although I can't verify whether you got the event, it seems to be an improvement in exception reporting.

Note: since this Sentry data seems to be rather small and is supposed to get cleaned up automatically by sending missed payloads later, it may be safe to use the default storage location even if the user chose a different one (if it's important to initialize Sentry as early as the game does right now and as long as there's a good way to access the default directory path). I don't really care about this trade-off though - you definitely know the game better than I do 👍