Right now, we only keep all configuration entries in a string map. This
is required to efficiently access configuration entries by keys. It has
the disadvantage of not being able to iterate through configuration
entries in the order they were read, though. Instead, we only iterate
through entries in a seemingly random order.

Extend `diskfile_entries` by another list holding configuration entries.
Like this, we maintain all entries in two data structures and can use
the required one based on the current use case.

Currently, we only parse the entry map into `append_entry` to append new
configuration entries to it. Instead, though, we can just pass the
complete `diskfile_entries` structure into it. This allows us to easily
extend `diskfile_entries` by another singly linked list of configuration
entries.

The config file parsing code all revolves around the `refcounted_strmap`
structure, which is a map of entry names to their respective keys. This
naming scheme made grasping the code quite hard, warranting a rename. A
good alternative is `diskfile_entries`, making clear that this really
only holds all configuration entries.

Furthermore, we are about to introduce a new linked list of
configuration entries into the configuration file code. This list will
be used to iterate over configuration entries in the order they are
listed inside of the parsed configuration file. After renaming
`refcounted_strmap` to `diskfile_entries`, this struct also becomes the
natural target where to add that new list. Like this, data structures
holding all entries are neatly contained inside of it.

The struct `parse_data` sounds as if it was defined and passed to us
from the configuration parser, which is not true. Instead, `parse_data`
is specific to the diskfile backend parsing logic. Rename it to
`diskfile_parse_state` to make that clearer. This also follows existing
naming patterns with the "diskfile" prefix.

The interface for freeing config list entries is more tangled than
required. Instead of calling `cvar_free` for every list entry in
`free_vars`, we now just provide a function `config_entry_list_free`.
This function will iterate through all list entries and free the
associated configuration entry as well as the list entry itself.

The `cvar_t` structure is really awkward to grasp, because its name
actively hinders discovery of what it actually is. As it is nothing more
than a singly-linked list of configuration entries, name rename it to
just that: `config_entry_list`.

In order to reject writes to included configuration entries, we need to
keep track of whether an entry was included via another configuration
file or not. This information is being stored in the `cvar` structure,
which is a rather weird location, as it is only used to create a list
structure of config entries.

Move the include depth into the structure `git_config_entry` instead.
While this fixes the layering issue, it enables users of libgit2 to
access the depth, too.

The code appending new configuration entries to our current list first
allocates the `cvar` structure and then passes it to `append_entry`. As
we want to extend `append_entry` to store configuration entries in a map
as well as in a list for ordered iteration, we will have to create two
`cvar` structures, though. As such, the future change will become much
easier when allocation of the `cvar` structure is doen in `append_entry`
itself.

We currently provide a lot of macros for the `cvar_t` structure which
are never being used. In fact, the only macro we need is to access the
`next` pointer of `cvar_t`, which really does not require a macro at
all.

Remove all these macros and replace usage of `CVAR_LIST_NEXT(cvar)` with
`cvar->next`.

Add myself to git.git-authors

odb: fix writing to fake write streams

In commit 7ec7aa4a (odb: assert on logic errors when writing objects,
2018-02-01), the check for whether we are trying to overflowing the fake
stream buffer was changed from returning an error to raising an assert.
The conversion forgot though that the logic around `assert`s are
basically inverted. Previously, if the statement

    stream->written + len > steram->size

evaluated to true, we would return a `-1`. Now we are asserting that
this statement is true, and in case it is not we will raise an error. So
the conversion to the `assert` in fact changed the behaviour to the
complete opposite intention.

Fix the assert by inverting its condition again and add a regression
test.

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.

online tests: update auth for bitbucket test

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

Refactor `gitno_extract_url_parts`

RFC 3986 says that hostnames can be percent encoded.  Percent decode
hostnames in our URLs.

Now that we can decode percent-encoded strings as part of `git_buf`s,
use that decoder in `gitno_extract_url_parts`.

Use `git_buf_decode_percent` so that we can avoid allocating a temporary
buffer.

Introduce a function to take a percent-encoded string (URI encoded,
described by RFC 1738) and decode it into a `git_buf`.

online::clone: skip creds fallback test

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.

pathspec: improve git_pathspec_flag_t doc rendering

Index parsing fixes

config: specify how we match the regular expressions

When computing the complete path length from the encoded
prefix-compressed path, we end up just allocating the complete path
without ever checking what the encoded path length actually is. This can
easily lead to a denial of service by just encoding an unreasonable long
path name inside of the index. Git already enforces a maximum path
length of 4096 bytes. As we also have that enforcement ready in some
places, just make sure that the resulting path is smaller than
GIT_PATH_MAX.

Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>

The index format in version 4 has prefix-compressed entries, where every
index entry can compress its path by using a path prefix of the previous
entry. Since implmenting support for this index format version in commit
5625d86b (index: support index v4, 2016-05-17), though, we do not
correctly verify that the prefix length that we want to reuse is
actually smaller or equal to the amount of characters than the length of
the previous index entry's path. This can lead to a an integer underflow
and subsequently to an out-of-bounds read.

Fix this by verifying that the prefix is actually smaller than the
previous entry's path length.

Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>

The function `read_entry` does not conform to our usual coding style of
returning stuff via the out parameter and to use the return value for
reporting errors. Due to most of our code conforming to that pattern, it
has become quite natural for us to actually return `-1` in case there is
any error, which has also slipped in with commit 5625d86b (index:
support index v4, 2016-05-17). As the function returns an `size_t` only,
though, the return value is wrapped around, causing the caller of
`read_tree` to continue with an invalid index entry. Ultimately, this
can lead to a double-free.

Improve code and fix the bug by converting the function to return the
index entry size via an out parameter and only using the return value to
indicate errors.

Reported-by: Krishna Ram Prakash R <krp@gtux.in>
Reported-by: Vivek Parikh <viv0411.parikh@gmail.com>

Integer overflow

deps: upgrade embedded zlib to version 1.2.11