The Git protocol does not specify what should happen in the case
of an empty packet line (that is a packet line "0004"). We
currently indicate success, but do not return a packet in the
case where we hit an empty line. The smart protocol was not
prepared to handle such packets in all cases, though, resulting
in a `NULL` pointer dereference.

Fix the issue by returning an error instead. As such kind of
packets is not even specified by upstream, this is the right
thing to do.

Each packet line in the Git protocol is prefixed by a four-byte
length of how much data will follow, which we parse in
`git_pkt_parse_line`. The transmitted length can either be equal
to zero in case of a flush packet or has to be at least of length
four, as it also includes the encoded length itself. Not
checking this may result in a buffer overflow as we directly pass
the length to functions which accept a `size_t` length as
parameter.

Fix the issue by verifying that non-flush packets have at least a
length of `PKT_LEN_SIZE`.

Documentation fixes

http: bump the pretend git version in the User-Agent

We want to keep the git UA in order for services to recognise that we're
a Git client and not a browser. But in order to stop dumb HTTP some
services have blocked UAs that claim to be pre-1.6.6 git.

Thread these needles by using the "git/2.0" prefix which is still close
enough to git's yet distinct enough that you can tell it's us.

sysdir: don't re-guess when using variable substitution

Don't hard-code HTTPS cap & clarify the meanings of the features enum

README: be more explicit in the goals and scope

Gift deprecated in favor of SwiftGit2

refdb: bubble up recursive rm when locking a ref

pack: dereference cached pack entry on error

Fix off-by-one problems in git_signature__parse

Make it clearer from the get-go that we do not aim to implement
user-facing commands from the git tool.

We should replace it with whatever the user set, not start again.

When given $PATH as part of a search path, we guess again instead of
substituting what the user already set.

Etc/GMT-14 aka UTC+14:00 is a thing....
https://en.wikipedia.org/wiki/UTC%2B14:00

Also allow offsets on the last minute (59).

Addresses: https://bugs.debian.org/841532
Fixes: #3970

Most importantly, clarify what it means for HTTPS and SSH to be supported.

This partially reverts bdec62dc which activates
the transport code-paths which allow you to use a custom TLS implementation
without having to have one at build-time.

However the capabilities describe how libgit2 was built, not what it could
potentially support, bring back the ifdefs so we only say we support HTTPS if
libgit2 was itself built with a TLS implementation.

rebase: plug a leak in the tests

Failure to bubble up this error means some locking errors do not get reported as
such on Windows.

refdb: disable concurrent compress in the threading tests on Windows

Various fixes

This is far from an ideal situation, but this causes issues on Windows which
make it harder to develop anything, as these tests hit issues which relate
specifically to the Windows filesystem like permission errors for files we
should be able to access. There is an issue likely related to the ordering of
the repack, but there's enough noise that it does not currently help us to run
this aspect of the test in CI.

When trying to uncompress deltas in a packfile's delta chain, we try to
add object bases to the packfile cache, subsequently decrementing its
reference count if it has been added successfully. This may lead to a
mismatched reference count in the case where we exit the loop early due
to an encountered error.

Fix the issue by decrementing the reference count in error cleanup.

The function `cl_git_thread_check()` is defined as static. As the
function is defined in a header file which is included by our
tests, this can result in warnings for every test file where
`cl_git_thread_check` is never used.

Fix the issue by marking it as inline instead.

git_rebase_init: correctly handle detached HEAD

Properly pass `wchar *` type to giterr_set

remote: fix typo in git_fetch_init_options docs

git_rebase_finish relies on head_detached being set, but
rebase_init_merge was only setting it when branch->ref_name was unset.
But branch->ref_name would be set to "HEAD" in the case of detached
HEAD being either implicitly (NULL) or explicitly passed to
git_rebase_init.