This is far from an ideal situation, but this causes issues on Windows which
make it harder to develop anything, as these tests hit issues which relate
specifically to the Windows filesystem like permission errors for files we
should be able to access. There is an issue likely related to the ordering of
the repack, but there's enough noise that it does not currently help us to run
this aspect of the test in CI.

git_rebase_init: correctly handle detached HEAD

Properly pass `wchar *` type to giterr_set

remote: fix typo in git_fetch_init_options docs

git_rebase_finish relies on head_detached being set, but
rebase_init_merge was only setting it when branch->ref_name was unset.
But branch->ref_name would be set to "HEAD" in the case of detached
HEAD being either implicitly (NULL) or explicitly passed to
git_rebase_init.

Introduce some clar helpers for child threads

Don't `cl_git_pass` in a child thread.  When the assertion fails, clar
will `longjmp` to its error handler, but:

> The effect of a call to longjmp() where initialization of the jmp_buf
> structure was not performed in the calling thread is undefined.

Instead, set up an error context that threads can populate, and the
caller can check.

We want a predictable number of initializations in our multithreaded
init test, but we also want to make sure that we have _actually_
initialized `git_libgit2_init` before calling `git_thread_create` (since
it now has a sanity check that `git_libgit2_init` has been called).

Since `git_thread_create` is internal-only, keep this sanity check.
Flip the invocation so that we `git_libgit2_init` before our thread
tests and `git_libgit2_shutdown` again after.

Introduce `git_thread_exit`, which will allow threads to terminate at an
arbitrary time, returning a `void *`.  On Windows, this means that we
need to store the current `git_thread` in TLS, so that we can set its
`return` value when terminating.

We cannot simply use `ExitThread`, since Win32 returns `DWORD`s from
threads; we return `void *`.

use `giterr_set_str()` wherever possible

`giterr_set()` is used when it is required to format a string, and since
we don't really require it for this case, it is better to stick to
`giterr_set_str()`.

This also suppresses a warning(-Wformat-security) raised by the compiler.

Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>

Bump version number to v0.25

sortedcache: plug leaked file descriptor

curl_stream: use CURLINFO_ACTIVESOCKET if curl is recent enough

Introduce a GitHub Issue Template

CHANGELOG: fill in some updates we missed

The `CURLINFO_LASTSOCKET` information has been deprecated since
curl version 7.45.0 as it may result in an overflow in the
returned socket on certain systems, most importantly on 64 bit
Windows. Instead, a new call `CURLINFO_ACTIVESOCKET` has been
added which instead returns a `curl_socket_t`, which is always
sufficiently long to store a socket.

As we need to provide backwards compatibility with curl versions
smaller than 7.45.0, alias CURLINFO_ACTIVESOCKET to
CURLINFO_LASTSOCKET on platforms without CURLINFO_ACTIVESOCKET.

Plug a leak in the refs compressor

Repository discovery starting from files

Use the sorted input in the tree updater

Concurrency fixes for the reference db

We look at whether we're trying to replace a blob with a tree during the
update phase, but we fail to look at whether we've just inserted a blob
where we're now trying to insert a tree.

Update the check to look at both places. The test for this was
previously succeeding due to the bu where we did not look at the sorted
output.

The loop is made with the assumption that the inputs are sorted and not
using it leads to bad outputs.

We do not currently use the sorted version of this input in the
function, which means we produce bad results.

On Windows we can find locked files even when reading a reference or the
packed-refs file. Bubble up the error in this case as well to allow
callers on Windows to retry more intelligently.

At times we may try to delete a reference which a different thread has
already taken care of.

It does not help us to check whether the file exists before trying to
unlink it since it might be gone by the time unlink is called.

Instead try to remove it and handle the resulting error if it did not
exist.

Checking the size before we open the file descriptor can lead to the
file being replaced from under us when renames aren't quite atomic, so
we can end up reading too little of the file, leading to us thinking the
file is corrupted.