Once upon a time, the `CLAR_RESOURCES` variable was intended to set
the `CLAR_RESOURCES` define. But actually, the define uses a wrong
variable name by accident, hinting that its value cannot actually be
used at all, as it is empty. Searching through the code base confirms
the guess that the define is not used at all.

Remove both the variable and definition.

While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`,
it is actually undefined due to us never including the "FindThreads"
module in the CMakeLists.txt. It is rather curious as to why this has
never triggered any error up to now, but it does in fact result in
linking errors on some Unix platforms as soon as we split up our build
instructions into multiple files.

Fix the issue now to avoid future breakage by including the
"FindThreads" module.

Include fixups

Docs: Fix inline comments for git_diff_hunk

oid: use memcmp in git_oid__hashcmp

sha1_lookup: drop sha1_entry_pos function

sha1_position: convert do-while to while

The open-coded version was inherited from git.git. But it
turns out it was based on an older version of glibc, whose
memcmp was not very optimized.

Modern glibc does much better, and some compilers (like gcc
7) can even inline the memcmp into a series of multi-byte
xors.

Upstream is switching to using memcmp in
git/git@0b006014c87f400bd9a86267ed30fd3e7b383884.

This was pulled over from git.git, and is an experiment in
making binary-searching lists of sha1s faster. It was never
compiled by default (nor was it used upstream by default
without a special environment variable).

Unfortunately, it is actually slower in practice, and
upstream is planning to drop it in
git/git@f1068efefe6dd3beaa89484db5e2db730b094e0b (which has
some timing results). It's worth doing the same here for
simplicity.

If we enter the sha1_position() function with "lo == hi",
we have no elements. But the do-while loop means that we'll
enter the loop body once anyway, picking "mi" at that same
value and comparing nonsense to our desired key. This is
unlikely to match in practice, but we still shouldn't be
looking at the memory in the first place.

This bug is inherited from git.git; it was fixed there in
e01580cfe01526ec2c4eb4899f776a82ade7e0e1.

patch_generate: represent buffers as void pointers

Remove unused 'sys/remote.h' header

tests: rebase::submodule: verify initialization method calls

Some return codes for functions which may fail are not being checked in
`test_rebase_submodule__initialize`. This may lead us to not notice
errors when initializing the environment and would possibly result in
either memory corruption or segfaults as soon as any of the
initialization steps fails. Fix this by wrapping these function calls
into `cl_git_pass`.

tests: rewrite rebase-submodule .gitmodule file

tsort: remove idempotent conditional assignment

Build with patched libcurl

win32: provide fast-path for retrying filesystem operations

When using the `do_with_retries` macro for retrying filesystem
operations in the posix emulation layer, allow the remediation function
to return `GIT_RETRY`, meaning that the error was believed to be
remediated, and the operation should be retried immediately, without
a sleep.

This is a slightly more general solution to the problem fixed in #4312.

Fixed an issue where the retry logic on p_unlink sleeps before it tries setting a file to write mode causing unnecessary slowdown.

Ubuntu trusty has a bug in curl when using NTLM credentials in a proxy,
dereferencing a null pointer and causing segmentation faults.  Use a
custom-patched version of libcurl that avoids this issue.

The conditional `run < minrun` can never be true directly after
assigning `run = minrun`. Remove it to avoid confusion.

Fixes #4274

Configuration file fixes with includes

Patch ID calculation

Modifying variables pulled in by an included file currently succeeds,
but it doesn't actually do what one would expect, as refreshing the
configuration will cause the values to reappear. As we are currently not
really able to support this use case, we will instead just return an
error for deleting and setting variables which were included via an
include.

Right now, we have multiple call sites which initialize a `reader`
structure. As the structure is only actually used inside of
`config_read`, we can instead just move the reader inside of the
`config_read` function. Instead, we can just pass in the configuration
file into `config_read`, which eases code readability.

Currently, we only re-parse the top-level configuration file when it has
changed itself. This can cause problems when an include is changed, as
we were not updating all values correctly.

Instead of conditionally reparsing only refreshed files, the logic
becomes much clearer and easier to follow if we always re-parse the
top-level configuration file when either the file itself or one of its
included configuration files has changed on disk. This commit implements
this logic.

Note that this might impact performance in some cases, as we need to
re-read all configuration files whenever any of the included files
changed. It could increase performance to just re-parse include files
which have actually changed, but this would compromise maintainability
of the code without much gain. The only case where we will gain anything
is when we actually use includes and when only these includes are
updated, which will probably be quite an unusual scenario to actually be
worthwhile to optimize.

The backend passed to `config_read` is never actually used anymore, so
we can remove it from the function and the `parse_data` structure.

Previously, the callbacks passed to `config_parse` got the reader via a
pointer to a pointer. This allowed the callbacks to update the callers
`reader` variable when the array holding it has been reallocated. As the
array is no longer present, we can simply the code by making the reader
a simple pointer.

Current code for configuration files uses the `reader` structure to
parse configuration files and store additional metadata like the file's
path and checksum. These structures are stored within an array in the
backend itself, which causes multiple problems.

First, it does not make sense to keep around the file's contents with
the backend itself. While this data is usually free'd before being added
to the backend, this brings along somewhat intricate lifecycle problems.
A better solution would be to store only the file paths as well as the
checksum of the currently parsed content only.

The second problem is that the `reader` structures are stored inside an
array. When re-parsing configuration files due to changed contents, we
may cause this array to be reallocated, requiring us to update pointers
hold by callers. Furthermore, we do not keep track of includes which
are already associated to a reader inside of this array. This causes us
to add readers multiple times to the backend, e.g. in the scenario of
refreshing configurations.

This commit fixes these shortcomings. We introduce a split between the
parsing data and the configuration file's metadata. The `reader` will
now only hold the file's contents and the parser state and the new
`config_file` structure holds the file's path and checksum. Furthermore,
the new structure is a recursive structure in that it will also hold
references to the files it directly includes. The diskfile is changed to
only store the top-level configuration file.

These changes allow us further refactorings and greatly simplify
understanding the code.