Use OAuth2 token for sync

chrome/browser/signin/oauth2_token_service.cc

Index: chrome/browser/signin/oauth2_token_service.cc
diff --git a/chrome/browser/signin/oauth2_token_service.cc b/chrome/browser/signin/oauth2_token_service.cc
index abddb4e8d46ba4b2febc36111848eddc313f8858..19772ca0800a37bceb6a1466b43e694a34564712 100644
--- a/chrome/browser/signin/oauth2_token_service.cc
+++ b/chrome/browser/signin/oauth2_token_service.cc
@@ -440,7 +440,7 @@ bool OAuth2TokenService::RemoveCacheEntry(
     const std::string& token_to_remove) {
   DCHECK(content::BrowserThread::CurrentlyOn(content::BrowserThread::UI));
   TokenCache::iterator token_iterator = token_cache_.find(scopes);
-  if (token_iterator == token_cache_.end() &&
+  if (token_iterator != token_cache_.end() &&

[tim (not reviewing), 2013/05/23 19:03:41]

I guess this wasn't being used very commonly?

[Andrew T Wilson (Slow), 2013/05/24 14:10:15]

I guess not. It's mostly an optimization anyway (if someone gets an error using
a token they can invalidate it so we try to re-fetch in the future - the fact
that this didn't work probably was masked by the fact that sync already
caught/reported auth errors).

[pavely, 2013/05/30 07:42:12]

If server returns AUTH_ERROR before token expires then sync should invalidate
access token with OAuth2TokenService, otherwise it is guaranteed to get the same
access token on consecutive token requests.

[Andrew T Wilson (Slow), 2013/05/31 12:57:28]

Yes. Since every token in OAuth2TokenService has an associated expiration date,
the idea is that it shouldn't be possible for the server to return an auth error
for a token prior to the OAuth2TokenService already figuring out that the token
is expired (except in the case that the user has invalid GAIA credentials/the
refresh token has been revoked).

So my point was, it's good to detect this case and tell OAuth2TokenService to
invalidate the token, but in general most services don't do this since in theory
this only happens from a race condition (service grabs token before it expires,
but then the token expires during the server request at which point
OAuth2TokenService has already expired it). That's why it doesn't surprise me
that there are bugs in this API - people aren't calling it. It's definitely more
correct to do what you are doing in Sync, though.

BTW, it'd be nice to add a test for this so it doesn't break in the future, but
I don't want to hold up this CL for that.

       token_iterator->second.access_token == token_to_remove) {
     token_cache_.erase(token_iterator);
     return true;