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.

When normalizing options we try to look up HEAD's OID. While this
action may fail in malformed repositories we never check the
return value of the function.

Fix the issue by converting `normalize_options` to actually
return an error and handle the error in `git_blame_file`.

We usually check entries returned by `git_sortedcache_entry` for
NULL pointers. As we have a write lock in `packed_write`, though,
it really should not happen that the function returns NULL.

Assert that ref is not NULL to silence a Coverity warning.

Curl by default does not report errors by setting the error code.
As the upload can fail through several conditions (e.g. the rate
limit, leading to unauthorized access) we should indicate this
information in Travis CI.

To improve upon the behavior, use `--write-out=%{http_code}` to
write out the HTTP code in addition to the received body and
return an error if the code does not equal 201.

When the user passes in a diff which has no repository associated
we may call `git_config__get_int_force` with a NULL-pointer
configuration. Even though `git_config__get_int_force` is
designed to swallow errors, it is not intended to be called with
a NULL pointer configuration.

Fix the issue by only calling `git_config__get_int_force` only
when configuration could be retrieved from the repository.

In C89 it is undefined behavior to pass `NULL` pointers to
`strncmp` and later on in C99 it has been explicitly stated that
functions with an argument declared as `size_t nmemb` specifying
the array length shall always have valid parameters, no matter if
`nmemb` is 0 or not (see ISO 9899 §7.21.1.2).

The function `str_equal_no_trailing_slash` always passes its
parameters to `strncmp` if their lengths match. This means if one
parameter is `NULL` and the other one either `NULL` or a string
with length 0 we will pass the pointers to `strncmp` and cause
undefined behavior.

Fix this by explicitly handling the case when both lengths are 0.