Git steps: implement auth by user/password

[tdesveaux]

This implement user/password authentication for the Git and GitPush steps (first part of #7384).

Authentication is handled with the builtin git credential flow using the git-credential-store backend.

Credentials are stored using git credential approve.
An alternative implementation could directly write the credential file that git-credential-store would read, but it's not supposed to be user facing (see doc: "Do not view or edit the file with editors") so might be subject to change in the future.
Whereas the git credential IOFormat is defined and should be stable.

Also, it allow to implement auth through another git-credential backend in the future if needed.

Credentials can be provided to the steps as a simple user/password tuple with auth_credentials, in which case, it will complete the auth form with the repourl the step is supposed to clone.
It's also possible to directly provide the git credential form through git_credentials (GitCredentialOptions). This might be needed for repositories that have submodule which are private and require a different set of credentials.

GitCredentialOptions also has a use_http_path member to override the config value of the same name. This is needed in case multiple credentials are needed for the same host (eg. GIthub repositories owner by different org/user). See doc.

I'll implement the same mechanism in GitPoller in another PR once this one is accepted as it require some more code change to provide a way for GitServiceAuth to run commands.

PS: Thanks for the async_to_deferred helper!

Contributor Checklist:

• I have updated the unit tests
• I have created a file in the newsfragments directory (and read the README.txt in that directory)
• I have updated the appropriate documentation

[p12tic]

FYI @async_to_deferred is only needed for externally callable APIs. Internal functions can be proper async because we can ensure that all call sites use either yield or await on it.

[p12tic]

Looks good, except single nit.

[tdesveaux]

FYI @async_to_deferred is only needed for externally callable APIs. Internal functions can be proper async because we can ensure that all call sites use either yield or await on it.

Since calling an async function from a deferred one (with yield) does not await the call, I felt it was less error prone to use the decorator on every async function, it could then be removed in the future when all code is async.

Other option would be to either propagate async conversion to caller (recursively) or use defer.fromCoroutine in the call code.

(might be helpful to set guidelines for async in #7371?).

[p12tic]

Since calling an async function from a deferred one (with yield) does not await the call, I felt it was less error prone to use the decorator on every async function, it could then be removed in the future when all code is async.

This is surprising. Supporting async functions from inlineCallbacks would be great migration strategy. I will check what's missing from it on twisted side, but this PR does not need to wait.

[tdesveaux]

I was surprised as well.
I even made a unit test to try the various combination between inlineCallback / pure async and async wrapped with async_to_deferred.

The only issue was when calling an async function from an inlineCallback with yield.