In commit 70a8fc999d (stop using fnmatch (either native or
compat), 2014-02-15), upstream git has switched over all code
from their internal fnmatch copy to its new wildmatch code. We
haven't followed suit, and thus have developed some
incompatibilities in how we match regular expressions.

Import git's wildmatch from v2.22.0 and add a test suite based on
their t3070-wildmatch.sh tests.

Modularize our TLS & hash detection

The interactions between `USE_HTTPS` and `SHA1_BACKEND` have been
streamlined. Previously we would have accepted not quite working
configurations (like, `-DUSE_HTTPS=OFF -DSHA1_BACKEND=OpenSSL`) and, as
the OpenSSL detection only ran with `USE_HTTPS`, the link would fail.

The detection was moved to a new `USE_SHA1`, modeled after `USE_HTTPS`,
which takes the values "CollisionDetection/Backend/Generic", to better
match how the "hashing backend" is selected, the default (ON) being
"CollisionDetection".

Note that, as `SHA1_BACKEND` is still used internally, you might need to
check what customization you're using it for.

tests: merge::analysis: use test variants to avoid duplicated test suites

Rename options initialization functions

deps: ntlmclient: disable implicit fallthrough warnings

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.

The ntlmclient dependency has quite a lot of places with implicit
fallthroughs. As at least modern GCC has enabled warnings on
implicit fallthroughs by default, the developer is greeted with a
wall of warnings when compiling that dependency.

Disable implicit fallthrough warnings for ntlmclient to fix this
issue.

gitignore with escapes

Handle URLs with a colon after host but no port

Our bundled http-parser includes bugfixes, therefore we should prefer
our http-parser until such time as we can identify that the system
http-parser has these bugfixes (using a version check).

Since these bugs are - at present - minor, retain the ability for users
to force that they want to use the system http-parser anyway.  This does
change the cmake specification so that people _must_ opt-in to the new
behavior knowingly.

Since commit 394951ad (tests: allow for simple data-driven
tests, 2019-06-07), we have the ability to run a given test suite
with multiple variants. Use this new feature to deduplicate the
test suites for merge::{trees,workdir}::analysis into a single
test suite.

Merge analysis support for bare repos

Add memleak check docs

In our attributes pattern parsing code, we have a comment that
states we might have to convert '\' characters to '/' to have
proper POSIX paths. But in fact, '\' characters are valid inside
the string and act as escape mechanism for various characters,
which is why we never want to convert those to POSIX directory
separators. Furthermore, gitignore patterns are specified to only
treat '/' as directory separators.

Remove the comment to avoid future confusion.

When determining the trailing space length, we need to honor
whether spaces are escaped or not. Currently, we do not check
whether the escape itself is escaped, though, which might
generate an off-by-one in that case as we will simply treat the
space as escaped.

Fix this by checking whether the backslashes preceding the space
are themselves escaped.

When parsing attribute patterns, we will eventually unescape the
parsed pattern. This is required because we require custom
escapes for whitespace characters, as normally they are used to
terminate the current pattern. Thing is, we don't only unescape
those whitespace characters, but in fact all escaped sequences.
So for example if the pattern was "\*", we unescape that to "*".
As this is directly passed to fnmatch(3) later, fnmatch would
treat it as a simple glob matching all files where it should
instead only match a file with name "*".

Fix the issue by unescaping spaces, only. Add a bunch of tests to
exercise escape parsing.

When parsing attributes, we need to search for the first
unescaped whitespace character to determine where the pattern is
to be cut off. The scan fails to account for the case where the
escaping '\' character is itself escaped, though, and thus we
would not recognize the cut-off point in patterns like "\\ ".

Refactor the scanning loop to remember whether the last character
was an escape character. If it was and the next character is a
'\', too, then we will reset to non-escaped mode again. Thus, we
now handle escaped whitespaces as well as escaped wildcards
correctly.

Windows-based systems treat paths starting with '\' as absolute,
either referring to the current drive's root (e.g. "\foo" might
refer to "C:\foo") or to a network path (e.g. "\\host\foo"). On
the other hand, (most?) systems that are not based on Win32
accept backslashes as valid characters that may be part of the
filename, and thus we cannot treat them to identify absolute
paths.

Change the logic to only paths starting with '\' as absolute on
the Win32 platform. Add tests to avoid regressions and document
behaviour.

Document how to run it locally on macOS & Linux

When the end of the host is reached, and we're at the colon separating
the host with the port (ie, there is no numeric port) then do not error.
This is allowed by RFC 3986.

Core git copes with URLs that have a colon after the port, but no actual
numeric value.  eg `http://example.com:/foo.git` or
`http://example.com:`.  That's horrible, but RFC 3986 says:

> URI producers and normalizers should omit the port component and its
> ":" delimiter if port is empty or if its value would be the same as
> that of the scheme's default.

Which indicates that they may and therefore we must accept it.

Test that we can handle URLs with a colon but no following port number.

Data-driven tests

sha1dc: update to fix endianess issues on AIX/HP-UX

Add NTLM support for HTTP(s) servers and proxies

Update our copy of sha1dc to the upstream commit 855827c (Detect
endianess on HP-UX, 2019-05-09). Changes include fixes to endian
detection on AIX and HP-UX systems as well as a define that
allows us to force aligned access, which we're not using yet.

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.

Include https://github.com/ethomson/ntlmclient as a dependency.

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.