reflogs: fix behaviour around reflogs with newlines

commit: verify objects exist in git_commit_with_signature

There can be a significant difference between the system where we created the
buffer (if at all) and when the caller provides us with the contents of a
commit.

Verify that the commit we are being asked to create references objects which do
exist in the target repository.

There can be a significant difference between the system where we created the
buffer (if at all) and when the caller provides us with the contents of a
commit.

Provide some test cases (we have to adapt the existing ones because they refer
to trees and commits which do not exist).

patch_parse: fixes for fuzzing errors

apply: add GIT_APPLY_CHECK

refs: unlock unmodified refs on transaction commit

This adds an option which will check if a diff is applicable without
actually applying it; equivalent to git apply --check.

When the patch contains lines close to INT_MAX, then it may happen that
we end up with an integer overflow when calculating the line of the
current diff hunk. Reject such patches as unreasonable to avoid the
integer overflow.

As the calculation is performed on integers, we introduce two new
helpers `git__add_int_overflow` and `git__sub_int_overflow` that perform
the integer overflow check in a generic way.

We've got two locations where we copy lines into the patch. The first
one is when copying normal " ", "-" or "+" lines, while the second
location gets executed when we copy "\ No newline at end of file" lines.
While the first one correctly uses `git__strndup` to copy only until the
newline, the other one doesn't. Thus, if the line occurs at the end of
the patch and if there is no terminating NUL character, then it may
result in an out-of-bounds read.

Fix the issue by using `git__strndup`, as was already done in the other
location. Furthermore, add allocation checks to both locations to detect
out-of-memory situations.

When parsing patch headers, we currently accept empty path names just
fine, e.g. a line "--- \n" would be parsed as the empty filename. This
is not a valid patch format and may cause `NULL` pointer accesses at a
later place as `git_buf_detach` will return `NULL` in that case.

Reject such patches as malformed with a nice error message.

It's currently possible to have patches with multiple old path name
headers. As we didn't check for this case, this resulted in a memory
leak when overwriting the old old path with the new old path because we
simply discarded the old pointer.

Instead of fixing this by free'ing the old pointer, we should reject
such patches altogether. It doesn't make any sense for the "---" or
"+++" markers to occur multiple times within a patch n the first place.
This also implicitly fixes the memory leak.

fuzzers: add a new fuzzer for patch parsing

In previous versions, libgit2 could be coerced into writing reflog
messages with embedded newlines into the reflog by using
`git_stash_save` with a message containing newlines. While the root
cause is fixed now, it was noticed that upstream git is in fact able to
read such corrupted reflog messages just fine.

Make the reflog parser more lenient in order to just skip over
malformatted reflog lines to bring us in line with git. This requires us
to change an existing test that verified that we do indeed _fail_ to
parse such logs.

The refdb_fs code to parse the reflog currently uses a hand-rolled
parser. Convert it to use our `git_parse_ctx` structure instead.

Currently, the reflog disallows any entries that have a message with
newlines, as that would effectively break the reflog format, which may
contain a single line per entry, only. Upstream git behaves a bit
differently, though, especially when considering stashes: instead of
rejecting any reflog entry with newlines, git will simply replace
newlines with spaces. E.g. executing 'git stash push -m "foo\nbar"' will
create a reflog entry with "foo bar" as entry message.

This commit adjusts our own logic to stop rejecting commit messages with
newlines. Previously, this logic was part of `git_reflog_append`, only.
There is a second place though where we add reflog entries, which is the
serialization code in the filesystem refdb. As it didn't contain any
sanity checks whatsoever, the refdb would have been perfectly happy to
write malformatted reflog entries to the disk. This is being fixed with
the same logic as for the reflog itself.

The code style of `git_stash_save` doesn't really match our current
coding style. Update it to match our current policies more closely.

I was looking at this code anyway because the sr.ht people nerdsniped
me, and it gave me that "I should fuzz this" feeling. So have a fuzzer!

patch_parse: handle patches without extended headers

Provide a wrapper for simple submodule clone steps

Add two more tests that verify our behaviour in some edge cases, notably
when cloning into a non-empty directory and when cloning the same
submodule twice.

The test submodule::add::submodule_clone doesn't use a sandbox, and thus
the created repo will not get deleted after the test has finished.
Convert the test to use the empty standard repo sandbox instead to fix
this.

The test submodule::add::homemade_clone unfortunately doesn't test
what's expected, but does instead clone the submodule to a directory
that is outside of the parent repository. Fixing this by cloning to the
correct location isn't possible, though, as `git_submodule_add_setup`
will have pre-created a ".git" file already, which will cause
`git_clone` to error out.

As it's not possible to perform the clone without fiddling around with
the repo's layout, let's just remove this test as that is in fact what
the new `git_submodule_clone` function is for.

Refs which are locked in a transaction without an altered target,
still should to be unlocked on `git_transaction_commit`.
`git_transaction_free` also unlocks refs but the moment of calling of `git_transaction_free`
cannot be controlled in all situations.
Some binding libs call `git_transaction_free` on garbage collection or not at all if the
application exits before and don't provide public access to `git_transaction_free`.
It is better to release locks as soon as possible.

macOS GSS Support

Extended header lines (especially the "index <hash>..<hash> <mode>") are
not required by "git apply" so it import patches. So we allow the
from-file/to-file lines (--- a/file\n+++ b/file) to directly follow the
git diff header.

This fixes #5267.

cmake: correct the link stanza for CoreFoundation

LIBRARIES is the (absolute?) path to the library.
LDFLAGS is the full linker stanza to correctly link with this lib.

By passing LIBRARIES as LIBGIT_LIBS, the linker ends up with the
absolute path for the SDK'ed version of CoreFoundation (which doesn't
exist), instead of the familiar `-framework CoreFoundation`.

Fix file locking on POSIX OS

cmake: update minimum CMake version to v3.5.1

The flag GIT_FILEBUF_FORCE currently does two things:
     1. It will cause the filebuf to create non-existing leading
        directories for the file that is about to be written.
     2. It will forcibly remove any pre-existing locks.
While most call sites actually do want (1), they do not want to
remove pre-existing locks, as that renders the locking mechanisms
effectively useless.
Introduce a new flag `GIT_FILEBUF_CREATE_LEADING_DIRS` to
separate both behaviours cleanly from each other and convert
callers to use it instead of `GIT_FILEBUF_FORCE` to have them
honor locked files correctly.

As this conversion removes all current users of `GIT_FILEBUF_FORCE`,
this commit removes the flag altogether.

patch_parse: handle patches with new empty files

Back in commit cf9f3452 (cmake: bump minimum version to 2.8.11,
2017-09-06), we have bumped the minimum CMake version to require at
least v2.8.11. The main hold-backs back then were distributions like
RHEL/CentOS as well as Ubuntu Trusty, which caused us to not target a
more modern version. Nowadays, Ubuntu Trusty has been EOL'd and CentOS 6
has CMake v3.6.1 available via the EPEL6 repository, and thus it seems
fair to upgrade to a more recent version.

Going through repology [1], one can see that all supported mainstream
distributions do in fact have CMake 3 available. Going through the list,
the minimum version that is supported by all mainstream distros is in
fact v3.5.1:

	- CentOS 6 via EPEL6: 3.6.1
	- Debian Oldstable: 3.7.2
	- Fedora 26: 3.8.2
	- OpenMandriva 3.x: 3.5.1
	- Slackware 14.2: 3.5.2
	- Ubuntu 16.04: 3.5.1

Consequentally, let's upgrade CMake to the minimum version of 3.5.1 and
remove all the version CMake checks that aren't required anymore.

[1]: https://repology.org/project/cmake/versions

DRY commit parsing