Sort out auth token refresh and setCredentials synchronization

[michpohl]

This fix makes auth networking more robust and predictable. While under normal circumstances the changes added here don't have an effect, making sure our SharedPreferences editing is synchronized with backend calls is necessary to enable certain types of UI tests (such as our benchmark tests) to run, as setCredentials can be called at any time.

When calling setCredentials, we essentially force credentials to be saved in the auth module's storage.
If we do this while a request for token update is in flight, we run the risk that upon return of that request, the credentials you just saved to be overwritten immediately.

This change fixes that by changing how our network calls are synchronized using a Mutex:

• it is now shared between LoginRepository and TokenRepository
• setCredentials is now synced too, making sure it will wait for all previously issued getCredentials calls to finish.

All following calls to getCredentials will be based on whatever was saved using setCredentials, so this change effectively prevents accidental overwrites for tests and other automated orchestration.

[stoyicker]

I haven't looked at the code yet, but from reading the description, it looks to me like this is the wrong approach. If calls to setCredentials need to prevail over ongoing updates, instead of waiting for ongoing/queued updates to complete, you should cancel ongoing/queued updates and execute on setCredentials calls immediately.

[michpohl]

I haven't looked at the code yet, but from reading the description, it looks to me like this is the wrong approach. If calls to setCredentials need to prevail over ongoing updates, instead of waiting for ongoing/queued updates to complete, you should cancel ongoing/queued updates and execute on setCredentials calls immediately.

On a conceptual level you might have a point, but it turned out to be pretty complex to solve the problem that way, which is why I ended up with this solution.
I'll give it another go though, maybe I find a better approach.

[michpohl]

@stoyicker see here for an alternative approach. This variant is out of the question for now - while seemingly correct it adds too much complexity and investing more time into bugproofing it is not warranted at this time.

[subhasha1]

If i understood correctly, this fix waits for any pending auth calls before applying values passed on setCredential.
Since setCredential's is only used internally,
I feel like this is perfectly acceptable solution to the problem we have.

I agree this can be further improved to an ideal implementation, but that might mean investing seemingly needless more engineering hours to the problem we would never have. imo, good to look further if thats quick