The base refspecs changing can be a cause of confusion as to what is the
current base refspec set and complicate saving the remote's
configuration.

Change `git_remote_add_{fetch,push}()` to update the configuration
instead of an instance.

This finally makes `git_remote_save()` a no-op, it will be removed in a
later commit.

Instead of having it set in a different place from every other callback,
put it the main structure. This removes some state from the remote and
makes it behave more like clone, where the constructors are passed via
the options.

Having the setting be different from calling its actions was not a great
idea and made for the sake of the wrong convenience.

Instead of that, accept either fetch options, push options or the
callbacks when dealing with the remote. The fetch options are currently
only the callbacks, but more options will be moved from setters and
getters on the remote to the options.

This does mean passing the same struct along the different functions but
the typical use-case will only call git_remote_fetch() or
git_remote_push() and so won't notice much difference.

When we have an HTTP stream and have set the certificatre check
callback, we currently fail as we ask the unencrypted stream for its
certificate.

This brings it in line with the rest of the lookup functions.

Signed-off-by: Sven Strickroth <email@cs-ware.de>

Signed-off-by: Sven Strickroth <email@cs-ware.de>

Skip it before we attempt to clone, as we would exit with -1 on systems
which do not have sshd running.

The user may have the data hashed as MD5 or SHA-1, so we should provide
both types for consumption.

Instead of using the libssh2 defines, provide our own, which eases usage
as we do not need to check whether libgit2 was built with libssh2 or not.

Instead of spreading the data in function arguments, some of which
aren't used for ssh and having a struct only for ssh, use a struct for
both, using a common parent to pass to the callback.

Test that the certificate check callback gets the right fingerprint from
the host we're connecting to.

On successful connection, still ask the user whether they accept the server's certificate, indicating that WinHTTP would let it though.

Returning 0 lets the certificate check succeed. An error code is bubbled
up to the user.

We know the host's key as soon as we connect, so we should perform the
check as soon as we can, before we bother with the user's credentials.

We should let the user decide whether to cancel the connection or not
regardless of whether our checks have decided that the certificate is
fine. We provide our own assessment to the callback to let the user fall
back to our checks if they so desire.

git allows you to set which paths to use for the git server programs
when connecting over ssh; and we want to provide something similar.

We do this by providing a factory function which can be set as the
remote's transport callback which will set the given paths upon
creation.

As git_clone now has callbacks to configure the details of the
repository and remote, remove the lower-level functions from the public
API, as they lack some of the logic from git_clone proper.

For urls where we do not specify a username, we must handle the case
where the ssh transport asks us for the username.

Test also that switching username fails.

In order to know which authentication methods are supported/allowed by
the ssh server, we need to send a NONE auth request, which needs a
username associated with it.

Most ssh server implementations do not allow switching the username
between authentication attempts, which means we cannot use a dummy
username and then switch. There are two ways around this.

The first is to use a different connection, which an earlier commit
implements, but this increases how long it takes to get set up, and
without knowing the right username, we cannot guarantee that the
list we get in response is the right one.

The second is what's implemented here: if there is no username specified
in the url, ask for it first. We can then ask for the list of auth
methods and use the user's credentials in the same connection.

Instead of completely giving up on the first failure, ask for
credentials as long as we fail to authenticate.

We need to be able to get a GIT_EUSER back through the outermost call.

Before calling the credentials callback, ask the sever which
authentication methods it supports and report that to the user, instead
of simply reporting everything that the transport supports.

In case of an error, we do fall back to listing all of them.

The assembla failure we were seeing referred to a private repository,
which is not what is there at the moment.

This reverts 1fd21b03

Don't write in plaintext the password of an account which has full
control over the repository. Instead use an account with read-only
access.

Show a failure to perform a mirror-clone from a repository, both local
and remote.