Refresh access tokens for TiclInvalidationService

Refresh access tokens for TiclInvalidationService

The Google Talk server will reject connection attempts made with a stale
access token.  This is often not a problem because we only need to
connect on startup, when the token is fresh.  It becomes a problem if we
temporarily lose the network connection and need to reconnect.

This change updates the TiclInvalidationService so it requests an
updated access token when it receives a credentials rejected error.
This should allow it to recover from connection failures caused by stale
access tokens.

TEST=Manual.  Sign in to sync, wait > 1 hour, disable network
connection, then re-enable it.  Verify notifier state is enabled.

BUG=264455
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=215094

[rlarocque, 2013-07-29 21:15:36]

Please review.

[tim (not reviewing), 2013-07-30 21:01:00]

LGTM with comment nit.

https://codereview.chromium.org/21140004/diff/1/chrome/browser/invalidation/t...
File chrome/browser/invalidation/ticl_invalidation_service.cc (right):

https://codereview.chromium.org/21140004/diff/1/chrome/browser/invalidation/t...
chrome/browser/invalidation/ticl_invalidation_service.cc:262: // This might not
be a real auth error.  Our access tokens expire
Maybe instead of "real", say  "This may simply be due to normal OAuth access
token expiration, which means we have to fetch a new one using our refresh
token."  And perhaps mention how the cycle is broken (?) in the event of a real
error?

[rlarocque, 2013-07-30 22:17:29]

+Fred to verify the accuracy of the new comment.

I should also note that fetching an access token should be cheap.  I believe the
classes that wrap that operation cache the access token and make sure to not
refresh it unless it has actually expired.

The behavior we end up with is:
- Exponential backoff + retry on the invalidator (XMPP connection).
- Attempt to refresh the access token at most once per
$ACCESS_TOKEN_EXPIRY_INTERVAL.
- If our refresh token is rejected (I believe this would happen if, for example,
the user's password changed), we enter an INVALIDATION_CREDENTIALS_REJECTED
state and stay there until we get a new refresh token.

[akalin, 2013-07-31 22:37:45]

lgtm

https://codereview.chromium.org/21140004/diff/10001/chrome/browser/invalidati...
File chrome/browser/invalidation/ticl_invalidation_service.cc (right):

https://codereview.chromium.org/21140004/diff/10001/chrome/browser/invalidati...
chrome/browser/invalidation/ticl_invalidation_service.cc:265: // it's safe to
try to update the token every time we receive this signal.
Add comment saying that if the credentials continue to be rejected
invalidator_registrar_ will be notified of that in OnGetTokenFailure.

[akalin, 2013-07-31 22:42:45]

https://codereview.chromium.org/21140004/diff/10001/chrome/browser/invalidati...
File chrome/browser/invalidation/ticl_invalidation_service.cc (right):

https://codereview.chromium.org/21140004/diff/10001/chrome/browser/invalidati...
chrome/browser/invalidation/ticl_invalidation_service.cc:265: // it's safe to
try to update the token every time we receive this signal.
per our discussion, transition to TRANSIENT_ERROR here while the token is being
fetched so that delegates know that the connection is (perhaps temporarily) down

[rlarocque, 2013-07-31 23:00:53]

https://codereview.chromium.org/21140004/diff/10001/chrome/browser/invalidati...
File chrome/browser/invalidation/ticl_invalidation_service.cc (right):

https://codereview.chromium.org/21140004/diff/10001/chrome/browser/invalidati...
chrome/browser/invalidation/ticl_invalidation_service.cc:265: // it's safe to
try to update the token every time we receive this signal.
On 2013/07/31 22:42:45, akalin wrote:
> per our discussion, transition to TRANSIENT_ERROR here while the token is
being
> fetched so that delegates know that the connection is (perhaps temporarily)
down

Done.

[commit-bot: I haz the power, 2013-08-01 17:18:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rlarocque@chromium.org/21140004/16001

[commit-bot: I haz the power, 2013-08-01 20:02:26]

Change committed as 215094