Since blame has been imported from git.git and had its first share of
refactorings in b6f60a4d (Clean up ported code, 2013-09-21), the code
is actually not doing the coalescing step of the generated blame. While
the code to do the coalescing does exist, it is never being called as
the function `git_blame__like_git` will directly return from its `while
(true)` loop.

The function that was being imported from git.git was the `assign_blame`
function from "builtin/blame.c" from 717d1462b (git-blame --incremental,
2007-01-28), which hasn't really changed much. Upon taking an initial
look, one can seet hat `coalesce` is actually never getting called in
`assign_blame`, as well, so one may assume that not calling `coalesce`
by accident is actually the right thing. But it is not, as `coalesce` is
being called ever since cee7f245d (git-pickaxe: blame rewritten.,
2006-10-19) after the blame has been done in the caller of
`assign_blame`. Thus we can conclude the code of libgit2 is actually
buggy since forever.

To fix the issue, simply break out of the loop instead of doing a direct
return. Note that this does not alter behaviour in any way visible to
our tests, which is unfortunate. But in order to not diverge from what
git.git does, I'd rather adapt to how it is being done upstream in order
to avoid breaking certain edge cases than to just remove that code.

types: remove unused git_merge_result

`git_merge_result` is currently unused in the codebase and generates a blank page in the [documentation](https://libgit2.github.com/libgit2/#HEAD/type/git_merge_result).

checkout: change default strategy to SAFE

As per #4200, our default is quite surprising to users that expect checkout to just "do the thing".

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

The current version of zlib bundled with libgit2 is version 1.2.8. This
version has several CVEs assigned:

- CVE-2016-9843
- CVE-2016-9841
- CVE-2016-9842
- CVE-2016-9840

Upgrade the bundled version to the current release 1.2.11, which has
these vulnerabilities fixes.

CHANGELOG: mention the change to `git_odb_open_rstream`

Worktree lock reason should be const