Make socket I/O non-blocking and add optional timeouts.
Users may now set `GIT_OPT_SET_SERVER_CONNECT_TIMEOUT` to set a shorter
connection timeout. (The connect timeout cannot be longer than the
operating system default.) Users may also now configure the socket read
and write timeouts with `GIT_OPT_SET_SERVER_TIMEOUT`.
By default, connects still timeout based on the operating system
defaults (typically 75 seconds) and socket read and writes block.
Add a test against our custom testing git server that ensures that we
can timeout reads against a slow server.
The `gitno` buffer interface is another layer on top of socket reads.
Abstract it a bit into a "static string" that has `git_str` like
semantics but without heap allocation which moves the actual reading
logic into the socket / stream code, and allows for easier future usage
of a static / stack-allocated `git_str`-like interface.
We lose some error information from the read / write callbacks to
stransport. Store our own error value in the object so that we can
ensure that we rely upon it.
`git__timer` is now `git_time_monotonic`, and returns milliseconds
since an arbitrary epoch.
Using a floating point to store the number of seconds elapsed was
clever, as it better supports the wide range of precision from the
different monotonic clocks of different systems. But we're a version
control system, not a real-time clock.
Milliseconds is a good enough precision for our work _and_ it's the
units that system calls like `poll` take and that our users interact
with.
Make `git_time_monotonic` return the monotonically increasing number
of milliseconds "ticked" since some arbitrary epoch.
git_oid_tostr_s could fail if thread-local state initialization fails.
In that case, it will now return `NULL`. Callers should check for
`NULL` and propagate the failure.
Thread-local storage data may fail to initialize; in this case, do not
try to set the error message into it. When the thread state has not
been initialized, return a hardcoded message to that affect.
Users should provide us an array of object ids; we don't need a separate
type. And especially, we should not be mutating user-providing values.
Instead, use `git_oid *` in the shallow code.
If `ENABLE_WERROR` is on, the CMake configure tests for the `qsort_r`
and `qsort_s` variants may fail due to warnings about unused functions
or unused parameters. These warnings can be ignored, so disable them
specifically for running those tests.
As reported in https://bugs.freebsd.org/271234, recent versions of
FreeBSD have adjusted the prototype for qsort_r() to match the POSIX
interface. This causes libgit2's CMake configuration check to fail to
detect qsort_r(), making it fall back to qsort_s(), which in libgit2
also has an incompatible interface. With recent versions of clang this
results in a "incompatible function pointer types" compile error.
Summarizing, there are four variations of 'qsort-with-context':
* old style BSD qsort_r(), used in FreeBSD 13 and earlier, where the
comparison function has the context parameter first
* GNU or POSIX qsort_r(), also used in FreeBSD 14 and later, where the
comparison function has the context parameter last
* C11 qsort_s(), where the comparison function has the context parameter
last
* Microsoft qsort_s(), where the comparison function has the context
parameter first
Add explicit detections for all these variants, so they get detected as
(in the same order as above):
* `GIT_QSORT_R_BSD`
* `GIT_QSORT_R_GNU`
* `GIT_QSORT_S_C11`
* `GIT_QSORT_S_MSC`
An additional complication is that on FreeBSD 14 and later, <stdlib.h>
uses the C11 _Generic() macro mechanism to automatically select the
correct qsort_r() prototype, depending on the caller's comparison
function argument. This breaks CMake's check_prototype_definition()
functionality, since it tries to redefine the function, and _Generic
macro is expanded inline causing a compile error.
Work around that problem by putting the function names in parentheses,
to prevent the preprocessor from using a macro to replace the function
name.
Also, in `git__qsort_r()`, change the `#if` order so the variants that
do not have to use glue are preferred.
The semantics of `from_file` are weird - it looks like a function that
just opens a file, but it actually inspects the pointer, which is
unexpected and could make things very crashy.
Make an `open` function that just does an open, and move the magic to
`open_or_refresh` whose name better indicates that it may do weird
stuff.
Use SHA256 for file checksums. SHA1 makes no sense as a default in 2023.
Given that we're just looking at a file checksum to see if it's changed,
this does not need to take repository's OID type into account or
otherwise be configurable.
