Our Docurium builds currently depend on Debian Jessie, which has CMake
v3.0 available. As rugged has bumped its CMake requirements to need at
least v3.5 now, the documentation build is thus failing.

Fix this by converting our Docurium Docker image to be based on Ubuntu
Bionic. We already do base all of our images on Ubuntu, so I don't see
any sense in using Debian here. If this was only to speed up builds, we
should just go all the way and use some minimal container like Alpine
anyway.

Also remove cache busters. As we're rebuilding the image every time,
it's we really don't need them at all.

We currently pass the "--silent" flag to most invocations of curl, but
in fact this does not only suppress the progress meter, but also any
errors. So let's also pass "--show-error", too.

The `CC_MD4()` function has been deprecated in macOS 10.15. Silence this
warning for now until we implement a proper fix.

The Secure Transport interface we're currently using has been deprecated
with macOS 10.15. As we're currently in code freeze, we cannot migrate
to newer interfaces. As such, let's disable deprecation warnings for
our "schannel.c" stream.

win32: don't canonicalize relative paths

Ensure that we don't canonicalize symlink targets.

Don't canonicalize symlink targets; our win32 path canonicalization
routines expect an absolute path.  In particular, using the path
canonicalization routines for symlink targets (introduced in commit
7d55bee6, "win32: fix relative symlinks pointing into dirs",
2020-01-10).

Now, use the utf8 -> utf16 relative path handling functions, so that
paths like "../foo" will be translated to "..\foo".

Add a function that takes a (possibly) relative UTF-8 path and emits a
UTF-16 path with forward slashes translated to backslashes.  If the
given path is, in fact, absolute, it will be translated to absolute path
handling rules.

The path canonicalization functions on win32 are intended to
canonicalize absolute paths; those with prefixes.  In other words,
things start with drive letters (`C:\`), share names (`\\server\share`),
or other prefixes (`\\?\`).

This function removes leading `..` that occur after the prefix but
before the directory/file portion (eg, turning `C:\..\..\..\foo` into
`C:\foo`).  This translation is not appropriate for local paths.

CMake booleans

Set proper pkg-config dependency for pcre2

httpclient: use a 16kb read buffer for macOS

Use a 16kb read buffer for compatibility with macOS SecureTransport.

SecureTransport `SSLRead` has the following behavior:

1. It will return _at most_ one TLS packet's worth of data, and
2. It will try to give you as much data as you asked for

This means that if you call `SSLRead` with a buffer size that is smaller
than what _it_ reads (in other words, the maximum size of a TLS packet),
then it will buffer that data for subsequent calls.  However, it will
also attempt to give you as much data as you requested in your SSLRead
call.  This means that it will guarantee a network read in the event
that it has buffered data.

Consider our 8kb buffer and a server sending us 12kb of data on an HTTP
Keep-Alive session.  Our first `SSLRead` will read the TLS packet off
the network.  It will return us the 8kb that we requested and buffer the
remaining 4kb.  Our second `SSLRead` call will see the 4kb that's
buffered and decide that it could give us an additional 4kb.  So it will
do a network read.

But there's nothing left to read; that was the end of the data.  The
HTTP server is waiting for us to provide a new request.  The server will
eventually time out, our `read` system call will return, `SSLRead` can
return back to us and we can make progress.

While technically correct, this is wildly ineffecient.  (Thanks, Tim
Apple!)

Moving us to use an internal buffer that is the maximum size of a TLS
packet (16kb) ensures that `SSLRead` will never buffer and it will
always return everything that it read (albeit decrypted).

Signed-off-by: Igor Raits <i.gnatenko.brain@gmail.com>

ci: provide globalsign certs for bionic

tls.mbed.org has neglected to send their full certificate chain.  Add
their intermediate cert manually.  🙄

deps: ntlmclient: fix htonll on big endian FreeBSD

azure-pipelines: download GlobalSign's certificate manually

tls.mbed.org has neglected to send their full certificate chain.  Add
their intermediate cert manually.  🙄

In commit 3828ea67 (deps: ntlmclient: fix missing htonll symbols on
FreeBSD and SunOS, 2020-02-21), we've fixed compilation on BSDs due to
missing `htonll` wrappers. While we are now using `htobe64` for both
Linux and OpenBSD, we decided to use `bswap64` on FreeBSD. While correct
on little endian systems, where we will swap from little- to big-endian,
we will also do the swap on big endian systems. As a result, we do not
use network byte order on such systems.

Fix the issue by using htobe64, as well.

deps: ntlmclient: fix missing htonll symbols on FreeBSD and SunOS

In the NTLM authentication code, we accidentally use strdup(3P) and
strndup(3P) instead of our own wrappers git__strdup and git__strndup,
respectively.

Fix the issue by using our own functions.

The ntlmclient dependency defines htonll on Linux-based systems, only.
As a result, non-Linux systems will run into compiler and/or linker
errors due to undefined symbols.

Fix this issue for FreeBSD, OpenBSD and SunOS/OpenSolaris by including
the proper headers and defining the symbol accordingly.

README: add language binding link to wasm-git

In order to check whether tracing support should be turned on, we check
whether ENABLE_TRACE equals "ON". This is being much too strict, as
CMake will also treat "on", "true", "yes" and others as true-ish, but
passing them will disable tracing support now.

Fix the issue by simply removing the STREQUAL, which will cause CMake to
do the right thing automatically.

Starting with our conversions to mix backend-autodetection and selection
into a single variable (USE_GSSAPI, USE_HTTPS, USE_SHA1), we have
introduced a simple STREQUAL to check for "ON", which indicates that the
user wants us to auto-detect available backends and pick any one that's
available. This behaviour deviates from previous behaviour, as passing a
value like "yes", "on" or "true" will in fact be treated like a backend
name and result in autodetection failure.

Fix the issue by introducing a new function `SanitizeBool`. Given a
variable that may hold a boolean value, the function will sanitize that
variable to hold either "ON" or "OFF". In case it is not a recognized
boolean, we will just keep the value as-is. This fixes the above
described issue.

Fix #5410: fix installing libgit2.pc in wrong location

Fix typo on GIT_USE_NEC

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

tests: diff: verify that we are able to diff with empty subtrees

README: update our build matrix to reflect current releases

azure: docker: set up HOME variable to fix Coverity builds

Remove using custom PKG_BUILD_PREFIu, PKG_BUILD_LIBDIR and
PKG_BUILD_INCLUDEDIR variables.
Use cmake CMAKE_INSTALL_PREFIX, LIB_INSTALL_DIR, INCLUDE_INSTALL_DIR instead.
This patch fixes install libgit2.pc file in correct location and simpifies
cmake module.

sha1_lookup: inline its only function into "pack.c"

Coverity fixes

In commit 01a83406 (azure: docker: fix ARM builds by replacing gosu(1),
2020-02-18), we've switched our entrypoint from gosu(1) to use sudo(1)
instead to fix our ARM builds. The switch introduced an incompatibility
that now causes our Coverity builds to fail, as the "--preserve-env"
switch will also keep HOME at its current value. As a result, Coverity
now tries to set up its configuration directory in root's home
directory, which it naturally can't write to.

Fix the issue by adding the "--set-home" flag to sudo(1).

As noted in docs/release.md, we only provide security updates for the
latest two releases. Let's thus drop the build status of both v0.27 and
v0.26 branches, adding the new v0.99 branch instead.

Release 0.99

Release script