WIP: Allow credential helper to provide SSH password

[w4]

What does this PR try to resolve?

I'm currently working on extending docs.rs to support our internal crate registry that usually uses SSH keys for authentication. However, since our crate registry is permissioned, we don't want all users to see all crates, nor should the docs.rs instance have unfettered access to the registry. Users authenticate to the docs.rs instance using an ephemeral OAuth token, and in turn we're using that token to pull from the registry if a new crate is discovered.

This works great for the pulling of .crate files since crates.io uses its own libgit2 instance we can hook into to provide credentials, however in the case of actually building the documentation it shells out to cargo to fetch dependencies. In this case, since Cargo uses the credential-helper as part of its authentication hooks for libgit2, we'd like to use that instead.

The credential-helper in this case is a very simple script that reads from the environment variables passed through on the Command invoked by docs.rs, git config --global credential.helper '!echo "username=oauth-token\npassword=${GIT_PASSWORD}"'. With this, we can use our ephemeral OAuth tokens as SSH passwords.

How should we test and review this PR?

The easiest way to test is temporarily removing your ssh keys from your agent and using username/password auth to depend on a Github repository.

Additional information

This is in draft whilst I keep hacking to see if there's a way around this by other means (maybe smuggling the token in the username via ssh_config and using git-fetch-with-cli or something, I did want to avoid that though for various reasons - or potentially pulling in Cargo as a library in docs.rs).

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue