Our mempack ODB backend has no test coverage at all right now. Add a
simple test suite to at least have some coverage of the most basic
operations on the ODB.

Update the settings to use a specific read-only token for accessing our
test repositories in Bitbucket.

At present, we have three online tests against bitbucket: one which
specifies the credentials in the payload, one which specifies the
correct credentials in the URL and a final one that specifies the
incorrect credentials in the URL.  Bitbucket has begun responding to the
latter test with a 403, which causes us to fail.

Break these three tests into separate tests so that we can skip the
latter until this is resolved on Bitbucket's end or until we can change
the test to a different provider.

Instead of laving it uninitialized and relying on luck for it to be non-zero,
let's give it a dummy hash so we make valgrind happy (in this case the hash
comes from `sha1sum </dev/null`.

Ensure that when examining the working directory for checkout that the
mode is correctly simplified.  Git only pays attention to whether a file
is executable or not.  When examining a working directory, we should
coalesce modes in the working directory to either `0755` (indicating
that a file is executable) or `0644` (indicating that it is not).

Test this by giving the file an exotic mode, and ensuring that when
checkout out a branch that changes the file's contents, that we do not
have a checkout conflict.

Add two tests for filemode.

The first ensures that `core.filemode=true` is honored: if we have
changed the filemode such that a file that _was_ executable (mode 0755)
is now executable (mode 0644) and we go to check out a branch that has
otherwise changed the contents of the file, then we should raise a
checkout conflict for that file.

The second ensures that `core.filemode=false` is honored: in the same
situation, we set a file that was executable to be non-executable, and
check out the branch that changes the contents of the file.  However,
since `core.filemode` is false, we do not detect the filemode change.

We run these tests on both operating systems that obey `core.filemode`
(eg, POSIX) and those that have no conception of filemode (eg, Win32).
This ensures that `core.filemode` is always honored, as it is a cache of
the underlying filesystem's settings.  This ensures that we do not
make assumptions based on the operating system, and honor the
configuration setting even if it were misconfigured.

Add a new branch to the `testrepo` repository, where the `README` file
has changed to executable.  This branch enables typechange tests between
the new `executable` branch and `master`.

When both the index _and_ the working directory has changed
permissions on a file permissions on a file - but only the permissions,
such that the contents of the file are identical - ensure that
`git_checkout` updates the permissions to match the checkout target.

When the working directory has changed permissions on a file - but only
the permissions, such that the contents of the file are identical -
ensure that `git_checkout` updates the permissions to match the checkout
target.

A rewritten file can either be classified as a modification of its
contents or of a delete of the complete file followed by an addition of
the new content. This distinction becomes important when we want to
detect renames for rewrites. Given a scenario where a file "a" has been
deleted and another file "b" has been renamed to "a", this should be
detected as a deletion of "a" followed by a rename of "a" -> "b". Thus,
splitting of the original rewrite into a delete/add pair is important
here.

This splitting is represented by a flag we can set at the current delta.
While the flag is already being set in case we want to break rewrites,
we do not do so in case where the `GIT_DIFF_FIND_RENAMES_FROM_REWRITES`
flag is set. This can trigger an assert when we try to match the source
and target deltas.

Fix the issue by setting the `GIT_DIFF_FLAG__TO_SPLIT` flag at the delta
when it is a rename target and `GIT_DIFF_FIND_RENAMES_FROM_REWRITES` is
set.

Add two more scenarios to the "renames" repository. The first scenario
has a major rewrite of a file and a delete of another file, the second
scenario has a deletion of a file and rename of another file to the
deleted file. Both scenarios will be used in the following commit.

While we frequently reuse commit OIDs throughout the file, we do not
have any constants to refer to these commits. Make this a bit easier to
read by giving the commit OIDs somewhat descriptive names of what kind
of commit they refer to.

The new index entry structure was not being initialized to all-zeroes.
As that structure is used to add a new entry to the current index, and
the hashing algorithm of the index making use of the uninitialized flags
to calculate the state, we might miscompute the hash of the entry and
add it at the wrong position. Later lookups would then fail.

Initialize the structure with `memset` to fix the test breaking on some
platforms.

Ensure that the buffer given to `git_index_add_frombuffer` represents a
regular blob, an executable blob, or a link.  Explicitly reject commit
entries (submodules) - it makes little sense to allow users to add a
submodule from a string; there's no possible path to success.

Return an error to the caller when we can't create an object header for
some reason (printf failure) instead of simply asserting.

The function `skip_bom` is being used to detect and skip BOM marks
previously to parsing a configuration file. To do so, it simply uses
`git_buf_text_detect_bom`. But since the refactoring to use the parser
interface in commit 9e66590b (config_parse: use common parser
interface, 2017-07-21), the BOM detection was actually broken.

The issue stems from a misunderstanding of `git_buf_text_detect_bom`. It
was assumed that its third parameter limits the length of the character
sequence that is to be analyzed, while in fact it was an offset at which
we want to detect the BOM. Fix the parameter to be `0` instead of the
buffer length, as we always want to check the beginning of the
configuration file.

Currently, the configuration parser will fail reading empty lines with
just an CRLF-style line ending. Special-case the '\r' character in order
to handle it the same as Unix-style line endings. Add tests to spot this
regression in the future.

Virtual base building: ensure that the virtual base is created and
revwalked in the same way as git.

When the commits being merged have multiple merge bases, reverse the
order when creating the virtual merge base.  This is for compatibility
with git's merge-recursive algorithm, and ensures that we build
identical trees.

Git does this to try to use older merge bases first.  Per 8918b0c:

> It seems to be the only sane way to do it: when a two-head merge is
> done, and the merge-base and one of the two branches agree, the
> merge assumes that the other branch has something new.
>
> If we start creating virtual commits from newer merge-bases, and go
> back to older merge-bases, and then merge with newer commits again,
> chances are that a patch is lost, _because_ the merge-base and the
> head agree on it. Unlikely, yes, but it happened to me.

Only run the large file tests on 64 bit platforms.

Even though we support streaming reads on objects, and do not need to
fit them in memory, we use `size_t` in various places to reflect the
size of an object.

Test that we can read_header on large blobs.  This should succeed on all
platforms since we read only a few bytes into memory to be able to
parse the header.

Since some test situations may have generous disk space, but limited RAM
(eg hosted build agents), test that we can stream a large file into a
loose object, and then stream it out of the loose object storage.

The null OID (hash with all zeroes) indicates a missing object in
upstream git and is thus not a valid object ID. Add defensive
measurements to avoid writing such a hash to the object database in the
very unlikely case where some data results in the null OID. Furthermore,
add shortcuts when reading the null OID from the ODB to avoid ever
returning an object when a faulty repository may contain the null OID.

In commit a96d3cc3f (cache-tree: reject entries with null sha1,
2017-04-21), the git.git project has changed its stance on null OIDs in
tree objects. Previously, null OIDs were accepted in tree entries to
help tools repair broken history. This resulted in some problems though
in that many code paths mistakenly passed null OIDs to be added to a
tree, which was not properly detected.

Align our own code base according to the upstream change and reject
writing tree entries early when the OID is all-zero.

Update the status::renames test to create an NFD format filename in the
core.precomposedunicode tests.

Previously, we would create an NFC format filename.  This was to take
advantage of HFS+ filesystems, which always use canonically decomposed
formats, and would actually write the filename to disk as an NFD
filename.  So previously, we could create an NFC filename, but read it
normally as an NFD filename.

But APFS formats do not force canonically decomposed formats for
filenames, so creating an NFC filename does not get converted to NFD.
Instead, the filename will be written in NFC format.  Our test,
therefore, does not work - when we write an NFC filename, it will
_remain_ NFC.

Update the test to write NFD always.  This will ensure that the file
will actually be canonically decomposed on all platforms:  HFS+, which
forces NFD, and APFS, which does not.

Thus, our test will continue to ensure that an NFD filename is
canonically precomposed on all filesystems.

Ensure that when the files being merged have CR/LF line endings that the
conflict markers produced in the conflict file also have CR/LF line
endings.

Git uses longer conflict markers in the recursive merge base - two more
than the default (thus, 9 character long conflict markers).  This allows
users to tell the difference between the recursive merge conflicts and
conflicts between the ours and theirs branches.

This was introduced in git d694a17986a28bbc19e2a6c32404ca24572e400f.

Update our tests to expect this as well.

The test refs::iterator::foreach_name iterates through every reference
and copies its name into a local vector. While the test makes sure to
free the vector afterwards, the copied reference names are not being
free'd. Fix that.

Two tests in network::fetchlocal explicitly set a cleanup function to
free and remove the created sandbox repositories. This is not necessary,
though, as the cleanup function executed after each test already takes
care of cleaning up after them. Remove the code to avoid needless code
duplication.