Instead of paging to zlib in INT_MAX sized chunks, we can give it
as many as UINT_MAX bytes at a time.  zlib doesn't care how big
a buffer we give it, this simply results in fewer calls into zlib.

zlib will only inflate/deflate an `int`s worth of data at a time.
We need to loop through large files in order to ensure that we inflate
the entire file, not just an `int`s worth of data.  Thankfully, we
already have this loop in our `git_zstream` layer.  Handle large objects
using the `git_zstream`.

Introduce an internal API to get the object type based on a
length-specified (not null terminated) string representation.  This can
be used to compare the (space terminated) object type name in a loose
object.

Reimplement `git_object_string2type` based on this API.

Introduce a test for very large objects in the ODB.  Write a large
object (5 GB) and ensure that the write succeeds and provides us the
expected object ID.  Introduce a test that writes that file and
ensures that we can subsequently read it.

Introduce `git_prefixncmp` that will search up to the first `n`
characters of a string to see if it is prefixed by another string.
This is useful for examining if a non-null terminated character
array is prefixed by a particular substring.

Consolidate the various implementations of `git__prefixcmp` around a
single core implementation and add some test cases to validate its
behavior.

zlib will return `Z_BUF_ERROR` whenever there is more input to inflate
or deflate than there is output to store the result.  This is normal for
us as we iterate through the input, particularly with very large input
buffers.

Add Jonathan Tan to git.git-authors

Jonathan has consented via email to have his contributions to git reused in libgit2

diff_file: properly refcount blobs when initializing file contents

libFuzzer: Fix missing trailer crash

When initializing a `git_diff_file_content` from a source whose data is
derived from a blob, we simply assign the blob's pointer to the
resulting struct without incrementing its refcount. Thus, the structure
can only be used as long as the blob is kept alive by the caller.

Fix the issue by using `git_blob_dup` instead of a direct assignment.
This function will increment the refcount of the blob without allocating
new memory, so it does exactly what we want. As
`git_diff_file_content__unload` already frees the blob when
`GIT_DIFF_FLAG__FREE_BLOB` is set, we don't need to add new code
handling the free but only have to set that flag correctly.

stransport: provide error message on trust failures

Fixes #4440

This change fixes an invalid memory access when the trailer is missing /
corrupt.

Found using libFuzzer.

libFuzzer: Fix a git_packfile_stream leak

This change ensures that the git_packfile_stream object in
git_indexer_append() does not leak when the stream has errors.

Found using libFuzzer.

Add git_status_file_at

openssl: fix thread-safety on non-glibc POSIX systems

diff_generate: fix unsetting diff flags

Use the same cert checking payload in WinHTTP

While the OpenSSL library provides all means to work safely in a
multi-threaded application, we fail to do so correctly. Quoting from
crypto_lock(3):

    OpenSSL can safely be used in multi-threaded applications provided
    that at least two callback functions are set, locking_function and
    threadid_func.

We do in fact provide the means to set up the locking function via
`git_openssl_set_locking()`, where we initialize a set of locks by using
the POSIX threads API and set the correct callback function to lock and
unlock them.

But what we do not do is setting the `threadid_func` callback. This
function is being used to correctly locate thread-local data of the
OpenSSL library and should thus return per-thread identifiers. Digging
deeper into OpenSSL's documentation, the library does provide a fallback
in case that locking function is not provided by the user. On Windows
and BeOS we should be safe, as it simply "uses the system's default
thread identifying API". On other platforms though OpenSSL will fall
back to using the address of `errno`, assuming it is thread-local.

While this assumption holds true for glibc-based systems, POSIX in fact
does not specify whether it is thread-local or not. Quoting from
errno(3p):

    It is unspecified whether errno is a macro or an identifier declared
    with external linkage.

And in fact, with musl there is at least one libc implementation which
simply declares `errno` as a simple `int` without being thread-local. On
those systems, the fallback threadid function of OpenSSL will not be
thread-safe.

Fix this by setting up our own callback for this setting. As users of
libgit2 may want to set it themselves, we obviously cannot always set
that function on initialization. But as we already set up primitives for
threading in `git_openssl_set_locking()`, this function becomes the
obvious choice where to implement the additional setup.

The macro `DIFF_FLAG_SET` can be used to set or unset a flag by
modifying the diff's bitmask. While the case of setting the flag is
handled correctly, the case of unsetting the flag was not. Instead of
inverting the flags, we are inverting the value which is used to decide
whether we want to set or unset the bits.

The value being used here is a simple `bool` which is `false`. As that
is being uplifted to `int` when getting the bitwise-complement, we will
end up retaining all bits inside of the bitmask. As that's only ever
used to set `GIT_DIFF_IGNORE_CASE`, we were actually always ignoring
case for generated diffs.

Fix that by instead getting the bitwise-complement of `FLAG`, not `VAL`.

In commit 9be638ec (git_diff_generated: abstract generated diffs,
2016-04-19), the code for generated diffs was moved out of the generic
"diff.c" and instead into its own module. During that conversion, it was
forgotten to remove the macros `DIFF_FLAG_IS_SET`, `DIFF_FLAG_ISNT_SET`
and `DIFF_FLAG_SET`, which are now only used in "diff_generated.c".

Remove those macros now.

CONTRIBUTING: add documentation of our commit message style

Include git2/worktree.h in git2.h

I'm not sure if worktree.h was intentionally left out of git2.h. Looks like an oversight since it is in fact documented.

Getting started README improvements

Introduce a simple FAQ for common errors for people getting started with
the project.

Since we recommend `ctest -V`, it's not clear why somebody would want to
run `libgit2_clar`.  Indicate that it's helpful when running individual
tests or suites.

Provide a very simple quick start paragraph that highlights how easy it
is to get started, and points people toward common problems.

Users should not be advised to use the VS command prompt; instead, they
should let cmake find their Visual Studio installation.

Suggest that users run `ctest -V` instead of `make test` when getting
started.  `ctest -V` is superior over alternatives as:

1. Unlike `make test`, it gives output.  Users getting started with
   the library believe that it is hung.
2. `ctest -V` shows verbose output; showing suite names is helpful for
   giving users more feedback immediately.

While we try to conform to a certain commit message style, this style
has never been documented anywhere. Document it such that new
contributors do not have to go through another needless iteration of
their pull requests just to fix up commit messages.

Gather the reflog entry content tests

diff: expose the "indent heuristic" in the diff options