We compute offsets by executing `off |= (*delta++ << 24)` for
multiple constants, where `off` is of type `size_t` and `delta`
is of type `unsigned char`. The usual arithmetic conversions (see
ISO C89 §3.2.1.5 "Usual arithmetic conversions") kick in here,
causing us to promote both operands to `int` and then extending
the result to an `unsigned long` when OR'ing it with `off`.
The integer promotion to `int` may result in wrong size
calculations for big values.

Fix the issue by making the constants `unsigned long`, causing both
operands to be promoted to `unsigned long`.

An object's size is computed by reading the object header's size
field until the most significant bit is not set anymore. To get
the total size, we increase the shift on each iteration and add
the shifted value to the total size.

We read the current value into a variable of type `unsigned
char`, from which we then take all bits except the most
significant bit and shift the result. We will end up with a
maximum shift of 60, but this exceeds the width of the value's
type, resulting in undefined behavior.

Fix the issue by instead reading the values into a variable of
type `unsigned long`, which matches the required width. This is
equivalent to git.git, which uses an `unsigned long` as well.

When `git_repository__cvar` fails we may end up with a
`ignorecase` value of `-1`. As we subsequently check if
`ignorecase` is non-zero, we may end up reporting that data
should be removed when in fact it should not.

Err on the safer side and set `ignorecase = 0` when
`git_repository__cvar` fails.

When we read the header, we want to know the size and type of the
object. We're currently inflating the full delta in order to read the
first few bytes. This can mean hundreds of kB needlessly inflated for
large objects.

Instead use a packfile stream to read just enough so we can read the two
varints in the header and avoid inflating most of the delta.

Include any required threading libraries in our `libgit2.pc`.

openssl_read should return -1 in case of error.

SSL_read returns values <= 0 in case of error.

A return value of 0 can lead to an infinite loop, so the return value
of ssl_set_error will be returned if SSL_read is not successful (analog
to openssl_write).

While no extra header fields are defined for tags, git accepts them by
ignoring them and continuing the search for the message. There are a few
tags like this in the wild which git parses just fine, so we should do
the same.

Backport bug fixes to 0.24

Instead of hoping that we can get a racy entry by going real fast
and praying real hard, just create a racy entry.

When running as root, skip the unreadable file tests, because, well,
they're probably _not_ unreadable to root unless you've got some
crazy NSA clearance-level honoring operating system shit going on.

Remove the now-unnecessary entries vector.  Add `git_array_search`
to binary search through an array to accomplish this.

Take advantage of the constant size of tree-owned arrays and store them
in an array instead of a pool. This still lets us free them all at once
but lets the system allocator do the work of fitting them in.

Instead of copying over the data into the individual entries, point to
the originals, which are already in a format we can use.

If we're looking for a symlink, realpath will give us the resolved path,
which is not what we're after, but a canonicalized version of the path
the user asked for.

If we hit the EOF while trying to write a new value, it may be that
we're already in the section that we were looking for.  If so, do not
write a (duplicate) section header, just write the value.

We should notice that we are in the correct section to add. This is a
cosmetic bug, since replacing any of these settings does work.

When we turned strict object creation validation on by default, we
forgot to inform the refs::create tests of this.  They, in fact,
believed that strict object creation was off by default.  As a result,
their cleanup function went and turned strict object creation off for
the remaining tests.

This lets us run with strict object creation on.

If we cannot dwim the input, set the error message to be explicit about
that. Otherwise we leave the error for the last failed lookup, which
can be rather unexpected as it mentions a remote when the user thought
they were trying to look up a branch.

When passing -DUSE_OPENSSL:BOOL=OFF to cmake the testsuite will
fail with the following error:

core::stream::register_tls [/tmp/libgit2/tests/core/stream.c:40]
  Function call failed: (error)
  error -1 - <no message>

Fix test to assume failure for tls when built without openssl.
While at it also fix GIT_WIN32 cpp to check if it's defined
or not.

Clang's documentation parser, which we use in our documentation system
does not report any comments for functions which use size_t as a type.

The root cause is buried somewhere in libclang but we can work around it
by defining the type ourselves. This typedef makes sure that libclang
sees it and that we do not change its size.

The xdl_prepare_env() function may initialise an xdlclassifier_t
data structure via xdl_init_classifier(), which allocates memory
to several fields, for example 'rchash', 'rcrecs' and 'ncha'.
If this function later exits due to the failure of xdl_optimize_ctxs(),
then this xdlclassifier_t structure, and the memory allocated to it,
is not cleaned up.

In order to fix the memory leak, insert a call to xdl_free_classifier()
before returning.

This patch was originally written by Ramsay Jones (see commit
87f16258367a3b9a62663b11f898a4a6f3c19d31 in git.git).

Commit 307ab20b3 ("xdiff: PATIENCE/HISTOGRAM are not independent option
bits", 19-02-2012) introduced the XDF_DIFF_ALG() macro to access the
flag bits used to represent the diff algorithm requested. In addition,
code which had used explicit manipulation of the flag bits was changed
to use the macros.

However, one example of direct manipulation remains. Update this code to
use the XDF_DIFF_ALG() macro.

This patch was originally written by Ramsay Jones (see commit
5cd6978a9cfef58de061a9525f3678ade479564d in git.git).

This special-casing ignores that we might have a locked file, so the
hashtable does not represent the contents of the file we want to
write. This causes multivar writes to overwrite entries instead of add
to them when under lock.

There is no need for this as the normal code-path will write to the file
just fine, so simply get rid of it.

The function to extract signatures suffers from a similar bug to the
header field finding one by having an unecessary line feed check as a
break condition of its loop.

Fix that and add a test for this single-line signature situation.

While often similar, these are not the same on Windows. We want to use the page
size on Windows for the pools, but for mmap we need to use the allocation
granularity as the alignment.

On the other platforms these values remain the same.

This is especially useful in combination with MinGW to yield the
Windows-compliant DLL name "git2.dll" instead of "libgit2.dll"

This is useful to force "smart" IDEs (like CLIon) to use debug
flag -g even it may have decided that "-D_DEBUG" (which is
already present) is sufficient.

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

Callers of `git_config__cvar` already handle the case where the
function returns an error due to a failed configuration variable
lookup, but we are actually swallowing errors when calling
`git_config__lookup_entry` inside of the function.

Fix this by returning early when `git_config__lookup_entry`
returns an error. As we call `git_config__lookup_entry` with
`no_errors == false` which leads us to call `get_entry` with
`GET_NO_MISSING` we will not return early when the lookup fails
due to a missing entry. Like this we are still able to set the
default value of the cvar and exit successfully.

When writing to a file with locking not check if writing the
locked file actually succeeds. Fix the issue by returning error
code and message when writing fails.