Object parsing fuzzer

config: Port config_file_fuzzer to the new in-memory backend.

Add a simple fuzzer that exercises our object parser code. The fuzzer
is quite trivial in that it simply passes the input data directly to
`git_object__from_raw` for each of the four object types.

When failing to parse a raw object fromits data, we free the
partially parsed object but then fail to propagate the error to the
caller. This may lead callers to operate on objects with invalid memory,
which will sooner or later cause the program to segfault.

Fix the issue by passing up the error code returned by `parse_raw`.

The standalone driver for libgit2's fuzzing targets makes use of
functions from libgit2 itself. While this is totally fine to do, we need
to make sure to always have libgit2 initialized via `git_libgit2_init`
before we call out to any of these. While this happens in most cases as
we call `LLVMFuzzerInitialize`, which is provided by our fuzzers and
which right now always calls `git_libgit2_init`, one exception to this
rule is our error path when not enough arguments have been given. In
this case, we will call `git_vector_free_deep` without libgit2 having
been initialized. As we did not set up our allocation functions in that
case, this will lead to a segmentation fault.

Fix the issue by always initializing and shutting down libgit2 in the
standalone driver. Note that we cannot let this replace the
initialization in `LLVMFuzzerInitialize`, as it is required when using
the "real" fuzzers by LLVM without our standalone driver. It's no
problem to call the initialization and deinitialization functions
multiple times, though.

Add some more tests for git_futils_rmdir_r and some cleanup

diff_stats: use git's formatting of renames with common directories

ignore unsupported http authentication contexts

auth_context_match returns 0 instead of -1 for unknown schemes to
not fail in situations where some authentication schemes are supported
and others are not.

apply_credentials is adjusted to handle auth_context_match returning
0 without producing authentication context.

submodule: ignore path and url attributes if they look like options

Smart packet security fixes

config_file: properly ignore includes without "path" value

These can be used to inject options in an implementation which performs a
recursive clone by executing an external command via crafted url and path
attributes such that it triggers a local executable to be run.

The library is not vulnerable as we do not rely on external executables but a
user of the library might be relying on that so we add this protection.

This matches this aspect of git's fix for CVE-2018-17456.

int-conversion

Currently, we do not clean up after ourselves after tests in core::rmdir
have created new files in the directory hierarchy. This may leave stale
files and/or directories after having run tests, confusing subsequent
tests that expect a pristine test environment. Most importantly, it may
cause the test initialization to fail which expects being able to
re-create the testing hierarchy before each test in case where another
test hasn't cleaned up after itself.

Fix the issue by adding a cleanup function that removes the temporary
testing hierarchy after each test if it still exists.

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

In case a configuration includes a key "include.path=" without any
value, the generated configuration entry will have its value set to
`NULL`. This is unexpected by the logic handling includes, and as soon
as we try to calculate the included path we will unconditionally
dereference that `NULL` pointer and thus segfault.

Fix the issue by returning early in both `parse_include` and
`parse_conditional_include` in case where the `file` argument is `NULL`.
Add a test to avoid future regression.

The issue has been found by the oss-fuzz project, issue 10810.

While our tests in config::include create a plethora of configuration
files, most of them do not get removed at the end of each test. This can
cause weird interactions with tests that are being run at a later stage
if these later tests try to create files or directories with the same
name as any of the created configuration files.

Fix the issue by unlinking all created files at the end of these tests.

While GCC enables int-conversion warnings by default, it will currently
only warn about such errors even in case where "-DENABLE_WERROR=ON" has
been passed to CMake. Explicitly enable int-conversion warnings by using
our `ENABLE_WARNINGS` macro, which will automatically use
"-Werror=int-conversions" in case it has been requested by the user.

GCC warns by default when implicitly converting integers to pointers or
the other way round, and commit fa48d2ea (vector: do not malloc
0-length vectors on dup, 2018-09-26) introduced such an implicit
conversion into our vector tests. While this is totally fine in this
test, as the pointer's value is never being used in the first place, we
can trivially avoid the warning by instead just inserting a pointer for
a variable allocated on the stack into the vector.

cmake: enable new quoted argument policy CMP0054

fix check if blob is uninteresting when inserting tree to packbuilder

In cases where a file gets renamed such that the directories containing
it previous and after the rename have a common prefix, then git will
avoid printing this prefix twice and instead format the rename as
"prefix/{old => new}". We currently didn't do anything like that, but
simply printed "prefix/old -> prefix/new".

Adjust our behaviour to instead match upstream. Adjust the test for this
behaviour to expect the new format.

Until now, we didn't have any tests that verified that our format for
renames in subdirectories is correct. While our current behaviour is no
different than for renames that do not happen with a common prefix
shared between old and new file name, we intend to change the format to
instead match the format that upstream git uses.

Add a test case for this to document our current behaviour and to show
how the next commit will change that format.

Quoting from CMP0054's documentation:

    Only interpret if() arguments as variables or keywords when
    unquoted.

    CMake 3.1 and above no longer implicitly dereference variables or
    interpret keywords in an if() command argument when it is a Quoted
    Argument or a Bracket Argument.

    The OLD behavior for this policy is to dereference variables and
    interpret keywords even if they are quoted or bracketed. The NEW
    behavior is to not dereference variables or interpret keywords that
    have been quoted or bracketed.

The previous behaviour could be quite unexpected. Quoted arguments might
be expanded in case where the value of the argument corresponds to a
variable. E.g. `IF("MONKEY" STREQUAL "MONKEY")` would have been expanded
to `IF("1" STREQUAL "1")` iff `SET(MONKEY 1)` was set. This behaviour
was weird, and recent CMake versions have started to complain about this
if they see ambiguous situations. Thus we want to disable it in favor of
the new behaviour.

Our CMake coding style dictates that there should be no space between
`IF` and its opening `(`. Adjust our policy statements to honor this
style.

Documentation fixups

Right now, we simply ignore the `linelen` parameter of
`git_pkt_parse_line` in case the caller passed in zero. But in fact, we
never want to assume anything about the provided buffer length and
always want the caller to pass in the available number of bytes.
And in fact, checking all the callers, one can see that the funciton is
never being called in case where the buffer length is zero, and thus we
are safe to remove this check.

The `parse_len` function currently directly returns the parsed length of
a packet line or an error code in case there was an error. Instead,
convert this to our usual style of using the return value as error code
only and returning the actual value via an out-parameter. Thus, we can
now convert the output parameter to an unsigned type, as the size of a
packet cannot ever be negative.

While at it, we also move the check whether the input buffer is long
enough into `parse_len` itself. We don't really want to pass around
potentially non-NUL-terminated buffers to functions without also passing
along the length, as this is dangerous in the unlikely case where other
callers for that function get added. Note that we need to make sure
though to not mess with `GIT_EBUFS` error codes, as these indicate not
an error to the caller but that he needs to fetch more data.

The parameters of the `git_pkt_parse_line` function are quite confusing.
First, there is no real indicator what the `out` parameter is actually
all about, and it's not really clear what the `bufflen` parameter refers
to. Reorder and rename the parameters to make this more obvious.

When checking whether an "unpack" packet returned the "ok" status or
not, we use a call to `git__prefixcmp`. In case where the passed line
isn't properly NUL terminated, though, this may overrun the line buffer.
Fix this by using `git__prefixncmp` instead.

When parsing "ng" packets, we blindly assume that the character
immediately following the "ng" prefix is a space and skip it. As the
calling function doesn't make sure that this is the case, we can thus
end up blindly accepting an invalid packet line.

Fix the issue by using `git__prefixncmp`, checking whether the line
starts with "ng ".

There are two different buffer overflows present when parsing "ok"
packets. First, we never verify whether the line already ends after
"ok", but directly go ahead and also try to skip the expected space
after "ok". Second, we then go ahead and use `strchr` to scan for the
terminating newline character. But in case where the line isn't
terminated correctly, this can overflow the line buffer.

Fix the issues by using `git__prefixncmp` to check for the "ok " prefix
and only checking for a trailing '\n' instead of using `memchr`. This
also fixes the issue of us always requiring a trailing '\n'.

Reported by oss-fuzz, issue 9749:

Crash Type: Heap-buffer-overflow READ {*}
Crash Address: 0x6310000389c0
Crash State:
  ok_pkt
  git_pkt_parse_line
  git_smart__store_refs

Sanitizer: address (ASAN)

We are being quite lenient when parsing "ACK" packets. First, we didn't
correctly verify that we're not overrunning the provided buffer length,
which we fix here by using `git__prefixncmp` instead of
`git__prefixcmp`. Second, we do not verify that the actual contents make
any sense at all, as we simply ignore errors when parsing the ACKs OID
and any unknown status strings. This may result in a parsed packet
structure with invalid contents, which is being silently passed to the
caller. This is being fixed by performing proper input validation and
checking of return codes.