Rich history may be supplied in such a way that fetching it requires
authentication. For example, Launchpad does this when referring to a
repository that does not exist, since a private repository may become
visible following authentication.
For rich history purposes, we should ignore this case and ensure that
git does not prompt the user for authentication but instead treat the
case as "rich history not provided".
It does not seem worth arranging a test for this, since we would need to
fake a remote repository that requires authentication and we don't
currently have (and until now have not needed) a test fixture for that.
I have tested this implementation manually. It is unlikely to regress in
our code base. If it were to regress because a future version of git
changes behaviour, then behaviour would revert back to a soft failure,
and we would be able to detect and debug the problem from there.
snapcraft regressed in that it now rejects apt signing keys that have
subkeys. This is reported upstream, but the easiest thing to do for now
is work around by not generating them. This diverges from gpg's default,
but subkeys are not needed for apt signing keys anyway.
Passing an empty cache dir to the launchpad download method pollutes the
working directory, causing the subsequent dpkg-buildpackage to fail.
Sidestep this bug and just use the tested code path instead.
