Publish GIDGoogleUser's tokens as immutable snapshots - #645

GIDGoogleUser wrote its access, refresh and ID tokens one property at a time - as a result, readers could see a mix of old & new tokens.

Behaviour change (in the CHANGELOG):

1. Observers of any of accessToken, refreshToken, idToken are now notified when any of the three changes. KVO observers run while the user's lock is held.
2. Calling back into the same user is fine, but an observer must not synchronously wait on another thread that is updating the same user.

The second behaviour change is an intentional tradeoff. The suggestion here was to send the KVO outside of the lock. That would mean out-of-order delivery could occur between any concurrent updates, and notifications be sent out-of-order. Sending outside of the lock would also mean that observers who ask KVO for the old value would get the new one. The only way for us to guarantee that there is no chance of deadlock; KVO freshness is correct; and notifications are delivered in-order would be to implement a manual notification queue.

Given that a deadlock would only occur when an observer is synchronously waiting on another thread that is also updating that same user; and that this behaviour has been present on the login path for some time; I judged that amount of manual machinery as not worth the tradeoff. Very willing to revisit in the future.