Add basic validation of stored credentials

[mjcheetham]

Right now GCM Core always returns any stored credentials for a request without any validation.

We cannot ever 100% validate that a credential is "good" for the particular Git command/request because the remote Git server can reject the credentials based on the content of the pack during a push, for example.

We can however validate if a stored a credential is expired or not, such as a PAT or OAuth JWT token that have expiration dates.

To do this we need to extend the credential store API and platform implementations to support reading/writing expiry metadata.

In the event the metadata is missing or the credentials have no expiry we should optimistically return them - assume they are good. This would mean we only reject definitely bad credentials (expired) and avoid false negatives.

[hickford]

extend the credential store API and platform implementations to support reading/writing expiry metadata

This would also work nicely for refresh tokens -- and a more elegant solution than storing under a distinct host.

I believe https://git-scm.com/docs/git-credential supports storing arbitrary key value pairs. [correction: it does not]

[hickford]

It would be neat to store Git's password_expiry_utc attribute https://git-scm.com/docs/git-credential#Documentation/git-credential.txt-codepasswordexpiryutccode

Currently GitLabHostProvider makes a HTTP request to check expiration. This would no longer be necessary. GenericHostProvider is unable to store expiry, so does OAuth refresh every time.

[becm]

The Git authentication flow will likely keep to enforce some limitations.
So the respective providers will need to handle most aspects of expiry and refresh during the get phase anyway.

The Azure and Bitbucket providers do some stuff with (dummy) web calls already.
Only missing one (at the moment)? should be generic OAuth2, expiry could be extracted from JWT content.
Trying to use that as part of #1837.

Also problematic:
The refresh_token MUST be updated as soon as there is a new value supplied by a reply.
The auth_token will take a detour via git and come around (depending on result) as a store or erase in a totally separate GCM invocation.
So they definitely have to remain as two distinctly changeable entities.