util: use 64 bit timer on Windows

Memory allocation audit

Our hand-rolled fallback sorting function `git__insertsort_r` does an
in-place sort of the given array. As elements may not necessarily be
pointers, it needs a way of swapping two values of arbitrary size, which
is currently implemented by allocating a temporary buffer of the
element's size. This is problematic, though, as the emulated `qsort`
interface doesn't provide any return values and thus cannot signal an
error if allocation of that temporary buffer has failed.

Convert the function to swap via a temporary buffer allocated on the
stack. Like this, it can `memcpy` contents of both elements in small
batches without requiring a heap allocation. The buffer size has been
chosen such that in most cases, a single iteration of copying will
suffice. Most importantly, it can fully contain `git_oid` structures and
pointers.

Add a bunch of tests for the `git__qsort_r` interface to verify nothing
breaks. Furthermore, this removes the declaration of `git__insertsort_r`
and makes it static as it is not used anywhere else.

The xdiff code contains multiple call sites where the results of
`xdl_malloc` are not being checked for memory allocation errors.

Add checks to fix possible segfaults due to `NULL` pointer accesses.

When allocating a chunk that is used to write to HTTP streams, we do not
check for memory allocation errors. This may lead us to write to a
`NULL` pointer and thus cause a segfault.

Fix this by adding a call to `GIT_ERROR_CHECK_ALLOC`.

The "trailer.c" code has been copied mostly verbatim from git.git with
minor adjustments, only. As git.git's `xmalloc` function, which aborts
on memory allocation errors, has been swapped out for `git_malloc`,
which doesn't abort, we may inadvertently access `NULL` pointers.

Add checks to fix this.

In "posix.c" there are multiple callsites which execute `malloc` instead
of `git__malloc`. Thus, users of library are not able to track these
allocations with a custom allocator.

Convert these call sites to use `git__malloc` instead.

When adding OIDs to the indexer's map of yet-to-be-seen OIDs to verify
that packfiles are complete, we do so by first allocating a new OID and
then calling `git_oidmap_set` on it. There was no check for memory
allocation errors in place, though, leading to possible segfaults due to
trying to copy data to a `NULL` pointer.

Verify the result of `git__malloc` with `GIT_ERROR_CHECK_ALLOC` to fix
the issue.

The function `git_commit_list_insert` dynamically allocates memory and
may thus fail to insert a given commit, but we didn't check for that in
several places in "merge.c".

Convert surrounding functions to return error codes and check whether
`git_commit_list_insert` was successful, returning an error if not.

The code in "blame_git.c" was mostly imported from git.git with only
minor changes. One of these changes was to use our own allocators
instead of git's `xmalloc`, but there's a subtle difference: `xmalloc`
would abort the program if unable to allocate any memory, bit
`git__malloc` doesn't. As we didn't check for memory allocation errors
in some places, we might inadvertently dereference a `NULL` pointer in
out-of-memory situations.

Convert multiple functions to return proper error codes and add calls to
`GIT_ERROR_CHECK_ALLOC` to fix this.

clone: don't decode URL percent encodings

Security updates from 0.28.3

The function `commit_quick_parse` provides a way to quickly parse
parts of a commit without storing or verifying most of its
metadata. The first thing it does is calculating the number of
parents by skipping "parent " lines until it finds the first
non-parent line. Afterwards, this parent count is passed to
`alloc_parents`, which will allocate an array to store all the
parent.

To calculate the amount of storage required for the parents
array, `alloc_parents` simply multiplicates the number of parents
with the respective elements's size. This already screams "buffer
overflow", and in fact this problem is getting worse by the
result being cast to an `uint32_t`.

In fact, triggering this is possible: git-hash-object(1) will
happily write a commit with multiple millions of parents for you.
I've stopped at 67,108,864 parents as git-hash-object(1)
unfortunately soaks up the complete object without streaming
anything to disk and thus will cause an OOM situation at a later
point. The point here is: this commit was about 4.1GB of size but
compressed down to 24MB and thus easy to distribute.

The above doesn't yet trigger the buffer overflow, thus. As the
array's elements are all pointers which are 8 bytes on 64 bit, we
need a total of 536,870,912 parents to trigger the overflow to
`0`. The effect is that we're now underallocating the array
and do an out-of-bound writes. As the buffer is kindly provided
by the adversary, this may easily result in code execution.

Extrapolating from the test file with 67m commits to the one with
536m commits results in a factor of 8. Thus the uncompressed
contents would be about 32GB in size and the compressed ones
192MB. While still easily distributable via the network, only
servers will have that amount of RAM and not cause an
out-of-memory condition previous to triggering the overflow. This
at least makes this attack not an easy vector for client-side use
of libgit2.

When the VirtualStore feature is in effect, it is safe to let random
users write into C:\ProgramData because other users won't see those
files. This seemed to be the case when we introduced support for
C:\ProgramData\Git\config.

However, when that feature is not in effect (which seems to be the case
in newer Windows 10 versions), we'd rather not use those files unless
they come from a trusted source, such as an administrator.

This change imitates the strategy chosen by PowerShell's native OpenSSH
port to Windows regarding host key files: if a system file is owned
neither by an administrator, a system account, or the current user, it
is ignored.

Will add later when infrastructure is configured

stash: avoid recomputing tree when committing worktree

Variadic macros

Add sign capability to git_rebase_commit

remote: remove unused block of code

Adjust printf specifiers in examples code

In "remote.c", we have a chunk of code that is #ifdef'fed out via
`#if 0` with a comment that we could export it as a helper function.
The code was implemented in 2013 and ifdef'fed in 2014, which shows that
there's clearly no interest in having such a helper at all.

As this block has recently created some confusion about `p_getenv` due
to it containing the only reference to that function in our codebase,
let's remove this block altogether.

config: check if we are running in a sandboxed environment

Static analysis of example code found multiple findings of `printf` usage
where filling value is members of git_indexer_progress object. Specifier
used was for signed int but git_indexer_progress members are typed as
unsigned ints. `printf` specifiers were altered to match type.

On macOS the $HOME environment variable returns the path to the sandbox container instead of the actual user $HOME for sandboxed apps. To get the correct path, we have to get it from the password file entry.

Fix example checkout to forbid rather than require --

editorconfig: update to match our coding style

Compare buffers in diff example

The macro `p_snprintf` is implemented as a variadic macro that
calls `snprintf` directly with `__VA_ARGS__`. In C89, variadic
macros are not allowed, but as the arguments of `p_snprintf` and
`snprintf` are matching 1:1, we can fix this by simply removing
the parameter list from `p_snprintf`.

The macro `apply_err` is implemented as a variadic macro, which
are not defined by C89. Convert it to a variadic function,
instead.

The macro `git_parse_error` is implemented in a variadic way so
that it's possible to pass printf-style parameters.
Unfortunately, variadic macros are not defined by C89 and thus we
cannot use that functionality. But as we have implemented
`git_error_vset` in the previous commit, we can now just use that
instead.

Convert `git_parse_error` to a variadic function and use
`git_error_vset` to fix the compliance violation. While at it,
move the function to "patch_parse.c".

Right now, we only provide a `git_error_set` that has a variadic
function signature. It's impossible to drive this function in a
C89-compliant way from other functions that have a variadic
signature, though, like for example `git_parse_error`.

Implement a new `git_error_vset` function that gets a `va_list`
as parameter, fixing the above problem.

Include ahead_behind in the test suite

config: separate file and snapshot backends

git__timer was originally implemented using a 32 bit timer since
Windows XP did not support GetTickCount64. Windows XP was discontinued
five years ago, so it should be safe to use the new API.

As a benefit, we do not need to care about overflows for the next 585
million years.

object: deprecate git_object__size for removal