Instead of running the oddball builds, run all the builds (the ones
that we always run during PR validation and CI) during a nightly
build for increased coverage.

strtol removal

 buf::oom tests: use custom allocator for oom failures

Create a custom allocator for the `buf::oom` tests that will fail with
out-of-memory errors in predictable ways.  We were previously trying to
guess the way that various allocators on various platforms would fail
in a way such that `malloc`/`realloc` would return `NULL` (instead of
aborting the application, or appearing suspicious to various
instrumentation or static code analysis tools like valgrind.)

Introduce a fake `malloc` and `realloc` that will return `NULL` on
allocations requesting more than 100 bytes.  Otherwise, we proxy to the
default allocator.  (It's important to use the _default_ allocator, not
just call `malloc`, since the default allocator on Windows CI builds may
be the debugging C runtime allocators which would not be compatible with
a standard `malloc`.)

Provide a utility to reset custom allocators back to their default.
This is particularly useful for testing.

ci: arm docker builds

We don't need two separate docker images for OpenSSL and mbedTLS.
They've been combined into a single image `trusty-amd64` that supports
both.

On a 32-bit Linux systems, the value large enough to make malloc
guarantee a failure is also large enough that valgrind considers it
"fishy".  Skip this test on those systems entirely.

Newer dependencies means newer places to leak!

Use Bionic so that we have a modern libssh2 (for communicating with
GitHub).  We've ported fixes to our Trusty-based amd64 images, but
maintaining patches for multiple platforms is heinous.

Bind the proxy specifically to 127.0.0.1 instead of all addresses.  This
is not strictly necessary for operations, but having a potentially open
proxy on a network is not a good idea.

Use multiarch arm32 and arm64 docker images to run Xenial-based images
for those platforms.  We can support all the tests on ARM32 and 64
_except_ the proxy-based tests.  Our proxy on ARM seems regrettably
unstable, either due to some shoddy dependencies (with native code?)
or the JREs themselves.

Run these platforms as part of our nightly builds; do not run them
during pull request or CI validation.

As the number of each grow, separate the CI build scripts from
the YAML definitions.

Win32 path canonicalization refactoring

Check object existence when creating a tree from an index

The testrepo test fixture has an index file that's damaged, missing an
object.  The index previously had an entry of `src/index.c` with id
3161df8cbf3a006b4ef85be6497a0ea6bde98541, but that object was missing in
the repository.  This commit adds an object to the repository and
updates the index to use that existing blob.

Similarly, the index has an entry for `readme` with an id of
97328ac7e3bd0bcd3900cb3e7a624d71dd0df888.  This can be restored from
other test repositories.

With these fixed, now the write tree from index tests can pass since they
validate object existence.

Ninja build

docs: fix transparent/opaque confusion in the conventions file

Configuration variables can appear on the same line as the section header

When an integer that is parsed with `git__strntol32` is too big to fit
into an int32, we will generate an error message that includes the
actual string that failed to parse. This does not acknowledge the fact
that the string may either not be NUL terminated or alternative include
additional characters after the number that is to be parsed. We may thus
end up printing characters into the buffer that aren't the number or,
worse, read out of bounds.

Fix the issue by utilizing the `endptr` that was set by
`git__strntol64`. This pointer is guaranteed to be set to the first
character following the number, and we can thus use it to compute the
width of the number that shall be printed. Create a test to verify that
we correctly truncate the number.

Update `git_win32_path_remove_namespace` to disambiguate the prefix
being removed versus the prefix being added.  Now we remove the
"namespace", and (may) add a "prefix" in its place.  Eg, we remove the
`\\?\` namespace.  We remove the `\\?\UNC\` namespace, and replace it
with the `\\` prefix.  This aids readability somewhat.

Additionally, use pointer arithmetic instead of offsets, which seems to
also help readability.

The internal API `git_win32__canonicalize_path` is far, far too easily
confused with the internal API `git_win32_path_canonicalize`.  The
former removes the namespace prefix from a path (eg, given
`\\?\C:\Temp\foo`, it returns `C:\Temp\foo`, and given
`\\?\UNC\server\share`, it returns `\\server\share`).  As such, rename
it to `git_win32_path_remove_namespace`.

`git_win32_path_canonicalize` remains unchanged.

While `git__strntol64` tries to detect integer overflows when doing the
necessary arithmetics to come up with the final result, it does the
detection only after the fact. This check thus relies on undefined
behavior of signed integer overflows. Fix this by instead checking
up-front whether the multiplications or additions will overflow.

Note that a detected overflow will not cause us to abort parsing the
current sequence of digits. In the case of an overflow, previous
behavior was to still set up the end pointer correctly to point to the
first character immediately after the currently parsed number. We do not
want to change this now as code may rely on the end pointer being set up
correctly even if the parsed number is too big to be represented as
64 bit integer.

Some edge cases were currently completely untested, e.g. parsing numbers
greater than INT64_{MIN,MAX}, truncating buffers by length and invalid
characters. Add tests to verify that the system under test performs as
expected.

The function `git__strtol32` can easily be misused when untrusted data
is passed to it that may not have been sanitized with trailing `NUL`
bytes. As all usages of this function have now been removed, we can
remove this function altogether to avoid future misuse of it.

Replace remaining uses of the `git__strtol32` function. While these uses
are all safe as the strings were either sanitized or from a trusted
source, we want to remove `git__strtol32` altogether to avoid future
misuse.

We use the `git__strtol32` function to parse the child and entry count
of treecaches from the index, which do not accept a buffer length. As
the buffer that is being passed in is untrusted data and may thus be
malformed and may not contain a terminating `NUL` byte, we can overrun
the buffer and thus perform an out-of-bounds read.

Fix the issue by uzing `git__strntol32` instead.

The function `git__strtol64` does not take a maximum buffer length as
parameter. This has led to some unsafe usages of this function, and as
such we may consider it as being unsafe to use. As we have now
eradicated all usages of this function, let's remove it completely to
avoid future misuse.

When parsing integers from configuration values, we use `git__strtol64`.
This is fine to do, as we always sanitize values and can thus be sure
that they'll have a terminating `NUL` byte. But as this is the last
call-site of `git__strtol64`, let's just pass in the length explicitly
by calling `strlen` on the value to be able to remove `git__strtol64`
altogether.

We use `git__strtol64` and `git__strtol32` to parse the trailing commit
or author date and timezone of signatures. As signatures are usually
part of a commit or tag object and thus essentially untrusted data, the
buffer may be misformatted and may not be `NUL` terminated. This may
lead to an out-of-bounds read.

Fix the issue by using `git__strntol64` and `git__strntol32` instead.

We use `git__strtol64` to parse file modes of the index entries, which
does not limit the parsed buffer length. As the index can be essentially
treated as "untrusted" in that the data stems from the file system, it
may be misformatted and may not contain terminating `NUL` bytes. This
may lead to out-of-bounds reads when trying to parse index entries with
such malformatted modes.

Fix the issue by using `git__strntol64` instead.

When quick-parsing a commit, we use `git__strtol64` to parse the
commit's time. The buffer that's passed to `commit_quick_parse` is the
raw data of an ODB object, though, whose data may not be properly
formatted and also does not have to be `NUL` terminated. This may lead
to out-of-bound reads.

Use `git__strntol64` to avoid this problem.