Add new function to set user within Sentry

[fpena]

Description

This PR adds a new public function to set a user object within Sentry.

[brendanlensink]

I think it might make more sense to bundle this user id within the SentryConfig class, since it seems to only be used for Sentry, does that make sense?

[fpena]

I think it might make more sense to bundle this user id within the SentryConfig class, since it seems to only be used for Sentry, does that make sense?

Thanks for the feedback @brendanlensink.

The reason I didn't do it like that is because setting a user (whether if we're passing a valid string or nil) is something you might want to run at least twice in an app. For example, after logging in and after logging out.

SentryConfig is a struct that gets passed when the Steamclog is initialized and happens only once.

Let me know if my thinking makes sense!

[nbrooke]

Couple overlapping things I don't like about this:

• Don't love prefixing classes with the name of the module, if this is gonna exist it should just be called "User" or "UserInfo" or something.
• A structure just to hold the one string to call one API and that is never stored seems like overkill. Seems like we could just have the API be setUser(userId: String?). I can sort of see the argument for having a container type IF there were a bunch of extra properties in there we were using, but just having one string to ID the user seems fine for the foreseeable future, and it's easy to add a container type later (and just have the single string API become a convenience wrapper) if we do ever want to do that.

[fpena]

@nbrooke feedback addressed.

[nbrooke]

Setting the user being a separate API rather than part of the config does make sense to me, for the reasons @fpena mentions. Even though it is Sentry specific now, it probably shouldn't be. Like in a case were were are using a different log destination that could support it (like Rollbar, which likely has an equivalent thing) the user should ALSO be passed through to that. Like ideally this should be something like:

public func setUser(userId: String?) {
    for destination in allDestinations {
        destination.setUser(userId: userId)
    } 
}

With setUser on the SentryDestination then having the current implementation.

I don't think there's really a good way to do that right now (because the protocols for log destinations are just inherited from XCGLogger), so it's probably not worth addressing just to get this working for right now, but maybe we should file a bug to generalize this at some point.

[brendanlensink]

Follow-up ticket filed here