Credential protocol enhancement: Retry mechanism and stateful operations

The Git credential protocol is really a set of three commands that credential helpers (such as GCM) should implement: get, store, and erase. The credential helpers are run with these commands as separate processes at different points of the overall Git remote operation, such as fetch or push.

Starting in Git version 2.46 the protocol now supports persisting state between get + store/erase command pairs. Since each credential helper command is invoked as a new process, it was previously not possible to persist metadata between calls. Examples of state that we may wish to keep are options to 'remember this account' to help with multi-account scenarios or maintain other caches of dynamically resolved information. 

Also starting in version 2.46, the protocol added the ability to advertise a multi-stage authentication process using the continue protocol key. This lets Git know that if a subsequent HTTP 401 response is encountered following an authenticated HTTP request, that this is not the end of the operation, and that the credential helper should be consulted once more. 

Using both the continue and state[] protocol capabilities, GCM will be able to perform optimistic account selection in the case of multiple accounts, or an available OS/broker account in the case of MSAL-based authentication. Without the ability to 'retry', selecting the wrong account means GCM doesn't get the opportunity to present an account selection, nor to understand that its previous 'best guess' was incorrect.

Author: @mjcheetham

Start by reviewing Git 2.46's credential protocol changes for the continue and state[] capabilities, then inspect how the credential helper handles separate get, store, and erase processes. Define the retry and stateful-operation behavior for GCM, including multi-account authentication, and add coverage demonstrating that a failed account selection can trigger another authentication attempt.