When allocating a chunk that is used to write to HTTP streams, we do not
check for memory allocation errors. This may lead us to write to a
`NULL` pointer and thus cause a segfault.

Fix this by adding a call to `GIT_ERROR_CHECK_ALLOC`.

In libgit2 nomenclature, when we need to verb a direct object, we name
a function `git_directobject_verb`.  Thus, if we need to init an options
structure named `git_foo_options`, then the name of the function that
does that should be `git_foo_options_init`.

The previous names of `git_foo_init_options` is close - it _sounds_ as
if it's initializing the options of a `foo`, but in fact
`git_foo_options` is its own noun that should be respected.

Deprecate the old names; they'll now call directly to the new ones.

When we send HTTP credentials but the server rejects them, tear down the
authentication context so that we can start fresh.  To maintain this
state, additionally move all of the authentication handling into
`on_auth_required`.

When we're issuing a CONNECT to a proxy, we expect to keep-alive to the
proxy.  However, during authentication negotiations, the proxy may close
the connection.  Reconnect if the server closes the connection.

When we have a keep-alive connection to the server, that server may
legally drop the connection for any reason once a successful request and
response has occurred.  It's common for servers to drop the connection
after some amount of time or number of requests have occurred.

We stop the read loop when we have read all the data.  We should also
consider the server's feelings.

If the server hangs up on us, we need to stop our read loop.  Otherwise,
we'll try to read from the server - and fail - ad infinitum.

Instead of using `is_complete` to decide whether we have connection or
request affinity for authentication mechanisms, set a boolean on the
mechanism definition itself.

For request-based authentication mechanisms (Basic, Digest) we should
keep the authentication context alive across socket connections, since
the authentication headers must be transmitted with every request.

However, we should continue to remove authentication contexts for
mechanisms with connection affinity (NTLM, Negotiate) since we need to
reauthenticate for every socket connection.

Hold an individual authentication context instead of trying to maintain
all the contexts; we can select the preferred context during the initial
negotiation.

Subsequent authentication steps will re-use the chosen authentication
(until such time as it's rejected) instead of trying to manage multiple
contexts when all but one will never be used (since we can only
authenticate with a single mechanism at a time.)

Also, when we're given a 401 or 407 in the middle of challenge/response
handling, short-circuit immediately without incrementing the retry
count.  The multi-step authentication is expected, and not a "retry" and
should not be penalized as such.

This means that we don't need to keep the contexts around and ensures
that we do not unnecessarily fail for too many retries when we have
challenge/response auth on a proxy and a server and potentially
redirects in play as well.

A "connection" to a server is transient, and we may reconnect to a
server in the midst of authentication failures (if the remote indicates
that we should, via `Connection: close`) or in a redirect.

Ensure that the server supports the particular credential type that
we're specifying.  Previously we considered credential types as an
input to an auth mechanism - since the HTTP transport only supported
default credentials (via negotiate) and username/password credentials
(via basic), this worked.  However, if we are to add another mechanism
that uses username/password credentials, we'll need to be careful to
identify the types that are accepted.

We must always consume the full parser body if we're going to
keep-alive.  So in the authentication failure case, continue advancing
the http message parser until it's complete, then we can retry the
connection.

Not doing so would mean that we have to tear the connection down and
start over.  Advancing through fully (even though we don't use the data)
will ensure that we can retry a connection with keep-alive.

When we get an authentication failure, we must consume the entire body
of the response.  If we only read half of the body (on the assumption
that we can ignore the rest) then we will never complete the parsing of
the message.  This means that we will never set the complete flag, and
our replay must actually tear down the connection and try again.

This is particularly problematic for stateful authentication mechanisms
(SPNEGO, NTLM) that require that we keep the connection alive.

Note that the prior code is only a problem when the 401 that we are
parsing is too large to be read in a single chunked read from the http
parser.

But now we will continue to invoke the http parser until we've got a
complete message in the authentication failed scenario.  Note that we
need not do anything with the message, so when we get an authentication
failed, we'll stop adding data to our buffer, we'll simply loop in the
parser and let it advance its internal state.

We cannot examine the keep-alive status of the http parser in
`http_connect`; it's too late and the critical information about whether
keep-alive is supported has been destroyed.

Per the documentation for `http_should_keep_alive`:

> If http_should_keep_alive() in the on_headers_complete or
> on_message_complete callback returns 0, then this should be
> the last message on the connection.

Query then and set the state.

Increase the permissible replay count; with multiple-step authentication
schemes (NTLM, Negotiate), proxy authentication and redirects, we need
to be mindful of the number of steps it takes to get connected.

7 seems high but can be exhausted quickly with just a single authentication
failure over a redirected multi-state authentication pipeline.

"Connection data" is an imprecise and largely incorrect name; these
structures are actually parsed URLs.  Provide a parser that takes a URL
string and produces a URL structure (if it is valid).

Separate the HTTP redirect handling logic from URL parsing, keeping a
`gitno_connection_data_handle_redirect` whose only job is redirect
handling logic and does not parse URLs itself.

Similar to the write(3) function, implementations of `git_stream_write`
do not guarantee that all bytes are written. Instead, they return the
number of bytes that actually have been written, which may be smaller
than the total number of bytes. Furthermore, due to an interface design
issue, we cannot ever write more than `SSIZE_MAX` bytes at once, as
otherwise we cannot represent the number of bytes written to the caller.

Unfortunately, no caller of `git_stream_write` ever checks the return
value, except to verify that no error occurred. Due to this, they are
susceptible to the case where only partial data has been written.

Fix this by introducing a new function `git_stream__write_full`. In
contrast to `git_stream_write`, it will always return either success or
failure, without returning the number of bytes written. Thus, it is able
to write all `SIZE_MAX` bytes and loop around `git_stream_write` until
all data has been written. Adjust all callers except the BIO callbacks
in our mbedtls and OpenSSL streams, which already do the right thing and
require the amount of bytes written.

Move to the `git_error` name in the internal API for error-related
functions.

Reset the replay_count upon a successful connection.  It's possible that
we could encounter a situation where we connect successfully but need to
replay a request - for example, a connection and initial request
succeeds without authentication but a subsequent call does require
authentication.  Reset the replay count upon any successful request to
afford subsequent replays room to manuever.

Temporarily disallow SSL connections to a proxy until we can understand
the valgrind warnings when tunneling OpenSSL over OpenSSL.

Only load the proxy configuration during connection; we need this data
when we're going to connect to the server, however we may mutate it
after connection (connecting through a CONNECT proxy means that we
should send requests like normal).  If we reload the proxy configuration
but do not actually reconnect (because we're in a keep-alive session)
then we will reload the proxy configuration that we should have mutated.

Thus, only load the proxy configuration when we know that we're going to
reconnect.

Don't allow servers to send us multiple Content-Type, Content-Length
or Location headers.

We previously used cURL to support HTTP proxies.  Now that we've added
this support natively, we can remove the curl dependency.

Natively support HTTPS connections through proxies by speaking CONNECT
to the proxy and then adding a TLS connection on top of the socket.

Introduce `git_tls_stream_wrap` which will take an existing `stream`
with an already connected socket and begin speaking TLS on top of it.
This is useful if you've built a connection to a proxy server and you
wish to begin CONNECT over it to tunnel a TLS connection.

Also update the pluggable TLS stream layer so that it can accept a
registration structure that provides an `init` and `wrap` function,
instead of a single initialization function.

Store the error message from the underlying TLS library before calling
the certificate callback.  If it refuses to act (demonstrated by
returning GIT_PASSTHROUGH) then restore the error message.  Otherwise,
if the callback does not set an error message, set a sensible default
that implicates the callback itself.

Refactor certificate checking so that it can easily be called for
proxies or the remote server.

Create a simple data structure that contains information about the
server being connected to, whether that's the actual remote endpoint
(git server) or an intermediate proxy.  This allows for organization of
streams, authentication state, etc.

Put a limit on the number of authentication replays in the HTTP
transport.  Standardize on 7 replays for authentication or redirects,
which matches the behavior of the WinHTTP transport.

Teach the HTTP transport how to prompt for proxy credentials.

Prepare credential handling to understand both git server and proxy
server authentication.

Factor credential handling into its own function.  Additionally, add
safety checks to ensure that we are in a valid state - that we have
received a valid challenge from the server and that we have
configuration to respond to that challenge.

The HTTP transport should understand how to apply proxies when
configured with `GIT_PROXY_SPECIFIED` and `GIT_PROXY_SPECIFIED`.
When a proxy is configured, the HTTP transport will now connect
to the proxy (instead of directly to the git server), and will
request the properly-formed URL of the git server endpoint.