(Local) UserService ID resolution #559
Description
There are some interesting quirks in the relationship between the web client's auth.service and its user.service (the one in the Utility module). The auth service basically sits on top of the OIDC library, and its responsibility more or less ends there. The user service relates the oidc profile to a Gameboard user. Due to the rxjs-ey way the user service is implemented, it can have an undefined value for the current user while the auth service's OIDC profile does indeed have a valid subject claim. This results in an odd situation where a check for a valid token and subject returns the expected value, but the user service's current user is undefined. This caused a bug in one of the guards, as at the time it gets evaluated on page reload, it doesn't have the user it needs (see here, where we had to work around by checking the auth service's claim instead).
Ultimately, I think exposing the auth service separately isn't that useful anyway. Ideally we'd rework these into a common service that has more stable behavior, but we're working around for now, and I don't think it's a massive architectural liability for now.