feat: disconnect upstream refreshing

[nabokihms]

Overview

PR14: Upstream refresh logic

What this PR does / why we need it

Connected #4560

Nobody refreshes upstream on every refresh request. Dex used to do this only because it didn't save user claims, but now we have a cache that updates on every login. There are risks of ending up with stale data, so I'd like to discuss the approach.

Special notes for your reviewer

[AlwxSin]

The DEP explicitly says UpdateUserIdentity should be called after a successful RefreshConnector.Refresh() to keep claims in sync.
So call upstream, update UserIdentity on success, fallback on failure (what DEP proposed) - this PR is close but missing the "update on success" part.
@nabokihms what exactly do you want to discuss?

[nabokihms]

The main concern is a new behaviour. It is inline with other providers like keycloak, ory or auth0, but for Dex it is a new thing. It is questionable...

[nabokihms]

It is also questionable do we really want to update in offline refreshing... maybe we can define a better rule when to call refresh in upstream (and do we really need to?)

[AlwxSin]

Ok, I dove in and here are my thoughts.
Correct me if I am wrong somewhere.

Option	Desc	Problem
A - Before	Always call upstream, fail on error	Break UX when upstream is unavailable
B - This PR	Call upstream, on error fallback to cache	Silent degradation, non-obvious behavior
C - Clean	Do not call upstream at all when sessions=on	Rely entirely on session TTL
D - Hard	Call upstream on schedule	More complex, but more flex

Option B creates unclear semantics - upstream refresh sometiomes works, then is silently ignored. If we are willing to absorb the upstream error anyway, option C is more logical - simply dont' call Refresh() when sessions are enabled. It's simpler, predictable and fairer to the user/admin.

[nabokihms]

Most providers do C. The only concern is that we will update user data less frequently... Users will have to log out and log in again to receive new claims, or wait till the session expires.

However, C is definitely better than B.

[AlwxSin]

Second call to storage after s.updateRefreshToken. Consider populate ident with LastLogin