Wrap function calls in the `checkout::crlf` tests with `cl_git_pass`,
`cl_assert`, etc. to ensure that they're successful.

This is a cherry-pick of the tests from the following commits:

core.autocrlf=true and core.safecrlf=true did not fail on LF-only file as vanilla git does
Adding a CRLF-file with core.autocrlf=input and core.safecrlf=true does not fail as with vanilla git
Make files with #CR!=#CRLF not fail with core.safecrlf=true

Reported-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Signed-off-by: Sven Strickroth <email@cs-ware.de>

Examine the recent CRLF changes to git by Torsten Bögershausen and
include similar changes to update our CRLF logic to match.

Note: Torsten Bögershausen has previously agreed to allow his changes to
be included in libgit2.

Don't simply fail when the expected output does not match the data in
the index; instead, provide a detailed output about the system, file,
and settings that caused the failure so that developers can better
isolate the problem(s).

Given a variety of combinations of core.autocrlf, core.safecrlf settings
and attributes settings, test that we add files to index the same way
(regarding OIDs and fatal errors) as a known-good test resource created
by git.git.

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

Use the crlf data scripts to produce a corpus of known-good data in
"git" format (aka ODB format) from a variety of files with different
line endings.  `git` created these files running `git add` to stage the
contents then extracting the data from the repository.

We'll use these to ensure that we create identical contents when we add
files into the index.

Re-use the existing crlf data generation script for creating the to-odb
dataset.  Also, store the actual file contents instead of the ID so that
we can identify differences instead of detecting that differences exist.

Include a shell script that will generate the expected data of OIDs and
failures for calling git.git to capture its output as a test resource.

Right now, there is no need to differentiate different systems as git behaves
the same on all systems IIRC.

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

After sandboxing the crlf directory, remove the working directory
contents.  This allows us to package data within the crlf directory
(for simplicity, this allows us to script the to-odb and to-workdir
crlf filter conversion data in a single location).

Move the crlf_data folders reponsible for holding the state of the
filters going into the working directory to "to_workdir" variations of
the folder name to accommodate future growth into the "to odb" filter
variation.  Update the script to create these new folders as appopriate.

Index API updates for consistency

Use the new object_type enumeration names within the codebase.

Use the new-style index names throughout our own codebase.

git_object_t is the future; update the public API to use it.  This will
also ensure that we can build our tests which make use of the old API
without modification (and without compiler warnings).

The two "reserved" bits in `git_object_t` are unused.  They were
included for completeness, but downstream users should never use them
and they should not have been made public.

These values are never set.

With the refactoring of `git_otype` into `git_object_t`, we can remove
these from the new API.  They will remain in the old (deprecated) API
in the unlikely event that someone was using them.

Update the `git_otype` names to reflect our current naming conventions.
`git_otype` is now `git_object_t` and the `GIT_OBJ_*` values are now
`GIT_OBJECT_*` values.

The old macro, enumeration and structure names are retained and simply
set to the new names.

We have various macro, enumeration and structure names that were
introduced (very) early in the project and do not match our current
naming conventions.  For instance: `GIT_IDXENTRY...` flags that
correspond to a structure named `git_index_entry`.

Update these to match the current guidance.  The old macros and
enumeration names are reflected as new macros in order to support
backward compatibility (and do so without warnings for consumers).

Allow merge analysis against any reference

revwalk: Allow changing hide_cb

Unused function warnings

Add builtin proxy support for the http transport

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.

Accept an enum (`git_stream_t`) during custom stream registration that
indicates whether the registration structure should be used for standard
(non-TLS) streams or TLS streams.

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.

Update the new stream registration API to be `git_stream_register`
which takes a registration structure and a TLS boolean.  This allows
callers to register non-TLS streams as well as TLS streams.

Provide `git_stream_register_tls` that takes just the init callback for
backward compatibliity.

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

The `-Wdocumentation-deprecated-sync` option will warn when there is a
doxygen `\deprecated` tag but there is no corresponding deprecation
attribute on the function.  We want to encourage users to not use
particular APIs by marking them deprecated in the documentation without
necessarily raising a compiler warning by marking an item as deprecated.

For testing, we may wish to use a man-in-the-middle proxy that can
inspect the CONNECT traffic to our test endpoints.  For this, we will
need to accept the proxy's certificate, which will not be valid for the
true endpoint.

Add a new environment variable, GITTEST_REMOTE_SSL_NOVERIFY to disable
https certificate validation for the tests.

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

The implementations of git_openssl_stream_new and
git_mbedtls_stream_new have callers protected by #ifdefs and
are never called unless compiled in.  There's no need for a
dummy implementation.  Remove them.

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.

Rename credential callback to proxy_cred_cb to match new cert callback.

Give the proxy tests a proxy certificate callback, and allow self-signed
certificates when the `GITTEST_REMOTE_PROXY_SELFSIGNED` environment
variable is set (to anything).  In that case, simply compare the hostname
from the callback to the hostname that we connected to.

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.