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

Cast less blindly between configuration objects

curl: initialize and cleanup global curl state

Instead of treating it as a no-op, treat it as a programming error and return
the same kind of error as if you called to set or delete variables on a
snapshot.

tree: initialize the id we use for testing submodule insertions

win32: strncmp -> git__strncmp for win32 STDCALL

Our curl-based streams make use of the easy curl interface. This
interface automatically initializes and de-initializes the global curl
state by calling out to `curl_global_init` and `curl_global_cleanup`.
Thus, all global state will be repeatedly re-initialized when creating
multiple curl streams in succession. Despite being inefficient, this is
not thread-safe due to `curl_global_init` being not thread-safe itself.
Thus a multi-threaded programing handling multiple curl streams at the
same time is inherently racy.

Fix the issue by globally initializing and cleaning up curl's state.

The win32 C library is compiled cdecl, however when configured with
`STDCALL=ON`, our functions (and function pointers) will use the stdcall
calling convention.  You cannot set a `__stdcall` function pointer to a
`__cdecl` function, so it's easier to just use our `git__strncmp`
instead of sorting that mess out.

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`.

When we create an iterator we don't actually know that we have a live config
object and we must instead only rely on the header. We fixed it to use this in a
previous commit, but this makes it harder to misuse by converting to use the
header object in the typecast.

We also guard inside the `config_refresh` function against being given a
snapshot (although callers right now do check).

We use it in a few places where we might have a full object or a snapshot so
move it to where we can actually access it.

We pass this around and when creating a new iterator we need to read the
repository pointer.

Put it in a common place so we can reach it regardless of whether we got a full
object or a snapshot.

Respect core.filemode in checkout

winhttp: enable TLS 1.2

Versions of Windows prior to Windows 8 do not enable TLS 1.2 by default,
though support may exist.  Try to enable TLS 1.2 support explicitly on
connections.

This request may fail if the operating system does not have TLS 1.2
support - the initial release of Vista lacks TLS 1.2 support (though
it is available as a software update) and XP completely lacks TLS 1.2
support.  If this request does fail, the HTTP context is still valid,
and still maintains the original protocol support.  So we ignore the
failure from this operation.

For platforms that do not define `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1`
and/or `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2`.

Include the constants for `WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_1` and
`WINHTTP_FLAG_SECURE_PROTOCOL_TLS1_2` so that they can be used by mingw.

This updates both the `deps/winhttp` framework (for classic mingw) and
adds the defines for mingw64, which does not use that framework.

travis: use custom libssh2-1-dev package

To avoid pull requests needing to rebase, keep the libssh2-1-dev
package as the development package for libssh2.  Reverting to the
original Debian package structure.

travis: use custom libssh2 package

Use the custom libssh2 package that is a backport of libssh2 1.8.0 to
Ubuntu trusty.

Fixes #4504

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`.

v0.27.0-rc1: version bump