fix: fix expiry for to_json()

[wescpy]

This patch for </issues/501> includes the following fixes:

• The access token is always set to None, so the fix involves using (the access) token from the saved JSON credentials file.
• For refresh needs, expiry also needs to be saved via to_json().
  • DUMP: As expiry is a datetime.datetime object, serialize to datetime.isoformat() in the same oauth2client format for consistency.
  • LOAD: Add code to restore expiry back to datetime.datetime object when imported.
  • LOAD: If expiry was unsaved, automatically set it as expired so refresh takes place.
• Minor scopes updates
  • DUMP: Add property for scopes so to_json() can grab it
  • LOAD: scopes may be saved as a string instead of a JSON array (Python list), so ensure it is Sequence[str] when imported.

[busunkim96]

@wescpy Thank you!

[gcf-merge-on-green]

Your PR has attempted to merge for 3 hours. Please check that all required checks have passed, you have an automerge label, and that all your reviewers have approved the PR

[gcf-merge-on-green]

Merge-on-green attempted to merge your PR for 6 hours, but it was not mergeable because either one of your required status checks failed, or one of your required reviews was not approved. Learn more about your required status checks here: https://help.github.com/en/github/administering-a-repository/enabling-required-status-checks. You can remove and reapply the label to re-run the bot.

[wescpy]

Thanks for looking at this! Not all the tests are passing (lint & cover), so I'm happy to help tweak/fix or work collaboratively to get them passing (unless you determine it's not necessary). In particular, I used this script to test various scenarios with this PR:

1. Unpatched, you always get "Re-run flow", even with valid but expired access tokens and valid NON-expired access tokens (because they're always set to None):

$ python bug501.py 
** Re-run flow: creds [True], valid? [False], expired [False]

2. With the access token fix in-place but no expiry, the access token would never be "expired" (the default), so w/o a timestamp, the client library makes it always "Valid" (incorrectly). A Google API would reject it as 400-something (invalid/expired), but the client library is smart and does a "refresh" under the hood. Unfortunately that "effort" is never saved back to the JSON file, so all calls to the API would continually refresh, which sux:

$ python bug501.py 
** "Valid" creds: creds [True], valid? [True], expired [False]

3. With the expiry patch in-place, a valid but expired access token give you "Auto-refresh" which is correct, and a valid NON-expired access token gives you "Valid", which is actually correct:

$ python bug501.py  # BEFORE refresh
** Auto-refresh: got creds? [True], valid? [False], expired? [True]
$ python bug501.py  # AFTER refresh
** "Valid" creds: creds [True], valid? [True], expired [False]

So while this script isn't a unit test, I'm going to try to roll this into the existing one </tests/oauth2/test_credentials.py>. LMK how else I can help in the meantime and stay tuned for another patch that should pass the unit tests.

[wescpy]

Fixed the black/linter reports; confused about pytest coverage output:

$ coverage report -m --fail-under=100
Name                               Stmts   Miss Branch BrPart  Cover   Missing
------------------------------------------------------------------------------
google/oauth2/__init__.py              1      0      0      0   100%
google/oauth2/_client.py              75      0      9      0   100%
google/oauth2/credentials.py         107      0     22      2    98%   264->267, 319->323
google/oauth2/id_token.py             48      0      6      0   100%
google/oauth2/service_account.py     117      0      6      0   100%
------------------------------------------------------------------------------
TOTAL                                348      0     43      2    99%
Coverage failure: total of 99 is less than fail-under=100

1. Code block 362-364 of test/oauth2/test_credentials.py covers 264-267 of google/oauth2/credentials.py, and ...
2. Code block 394-408 covers 319-323... what am I missing? Thanks!

[busunkim96]

@wescpy Apologies for leaving this unattended for so long. I will take a closer look at coverage this week and get back to you.

[wescpy]

SGTM @busunkim96 ... I've been on vaca anyway (back tmrw). :-)