Update the settings to use a specific read-only token for accessing our
test repositories in Bitbucket.

At present, we have three online tests against bitbucket: one which
specifies the credentials in the payload, one which specifies the
correct credentials in the URL and a final one that specifies the
incorrect credentials in the URL.  Bitbucket has begun responding to the
latter test with a 403, which causes us to fail.

Break these three tests into separate tests so that we can skip the
latter until this is resolved on Bitbucket's end or until we can change
the test to a different provider.

Validate using the http://user:pass@host/ format in HTTP_PROXY and
HTTPS_PROXY environment variables.

Right now, we test our credential callback code twice, once via SSH on
localhost and once via a non-existent GitHub repository. While the first
URL makes sense to be configurable, it does not make sense to hard-code
the non-existing repository, which requires us to call tests multiple
times. Instead, we can just inline the URL into another set of tests.

We support two types of passing credentials to the proxy, either via the
URL or explicitly by specifying user and password. We test these types
by modifying the proxy URL and executing the tests twice, which is
in fact unnecessary and requires us to maintain the list of environment
variables and test executions across multiple CI infrastructures.

To fix the situation, we can just always pass the host, port, user and
password to the tests. The tests can then assemble the complete URL
either with or without included credentials, allowing us to test both
cases in-process.

All our tests running against a local SSH server usually read the
server's URL from environment variables. But online::clone::ssh_cert
test fails to do so and instead always connects to
"ssh://localhost/foo". This assumption breaks whenever the SSH server is
not running on the standard port, e.g. when it is running as a user.

Fix the issue by using the URL provided by the environment.

The repository URL is duplicated several times and can be de-duplicated
like this. Furthermore, exchange the static refspec variable with a
define to reduce BSS size.

There are only few actions which actually make sense for a detached
remote, like e.g. `git_remote_ls`, `git_remote_prune`. For all the other
actions, we have to report an error when the remote has no repository
attached to it. This commit does so and implements some tests.

None of our crypto backends actually reject RC4 as a cipher so don't
test for it and instead keep it as something we'd like to do.

We must make sure that we're getting a certificate error from the
library so we know that we're testing the right thing.

Make sure that the callbacks do also get a 'valid' value of zero when
the certificate we're looking at is in valid and assert that within the
test.

According to git-fetch(1), "[t]he colon can be omitted when <dst>
is empty." So according to git, the refspec "refs/heads/master"
is the same as the refspec "refs/heads/master:" when fetching
changes. When trying to fetch from a remote with a trailing
colon with libgit2, though, the fetch actually fails while it
works when the trailing colon is left out. So obviously, libgit2
does _not_ treat these two refspec formats the same for fetches.

The problem results from parsing refspecs, where the resulting
refspec has its destination set to an empty string in the case of
a trailing colon and to a `NULL` pointer in the case of no
trailing colon. When passing this to our DWIM machinery, the
empty string gets translated to "refs/heads/", which is simply
wrong.

Fix the problem by having the parsing machinery treat both cases
the same for fetch refspecs.

We leave this up to the scheme in the url field. The type should only
tell us about whether we want a proxy and whether we want to auto-detect
it.

This ensures that when using OpenSSL a safe default set of ciphers
is selected. This is done so that the client communicates securely
and we don't accidentally enable unsafe ciphers like RC4, or even
worse some old export ciphers.

Implements the first part of https://github.com/libgit2/libgit2/issues/3682

If none of GIT_OPENSSL, GIT_WINHTTP or GIT_SECURE_TRANSPORT
is defined we should also be able to build the unit test.

These provide bad X.509 certificates, which we should refuse to connect
to by default.

These are small pieces of data, so there is no advantage to allocating
them separately. Include the two ids inline in the struct we use to
check that the expected and actual ids match.

Also, *some* custom headers actually are valid.

Introduce `git__getenv` which is a UTF-8 aware `getenv` everywhere.
Make `cl_getenv` use this to keep consistent memory handling around
return values (free everywhere, as opposed to only some platforms).

We need to pass these options in order to have the credentials callback
set.

The code used to rely on the clone code calling the remote's save, which
does not happen anymore, meaning that the configuration settings the
remote expected were not being written to disk.

The run-time configuration was still being affected, so the right branch
was being cloned. The tests continued to pass as we did not check for
the configuration entires. Fix this by creating the remote with the
single-branch refspec we want and checking for its existence in the
configuration.

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.

This is another option which we should not be keeping in the remote, but
is specific to each particular operation.

While this will rarely be different from the default, having it in the
remote adds yet another setting it has to keep around and can affect its
behaviour. Move it to the options.

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.

Moved offending tests from network to online so they will get skipped
when there is a lack of network connectivity:
-test_online_remotes__single_branch
-test_online_remotes__restricted_refspecs

It can be useful for the caller to know which update commands will be
sent to the server before the packfile is pushed up. git does this via
the pre-push hook.

We don't have hooks, but as it adds introspection into what is
happening, we can add a callback which performs the same function.