The opaque `payload` on an entry is unnecessary and distracting; config
entries should follow the patterns of other objects and use space
elsewhere in the structure with a "base" config entry struct embedded.

Don't set entry data when we "get" an entry from the collection, add the
data to the entry before it's put into the collection. This keeps the
entry creation logic in a single place.

We are allowed to call `git_repository__cleanup` multiple times, and this
happens e.g. in rugged if we want to free up resources before GC gets around to
them.

This means that we cannot leave dangling pointers in it, which we were doing
with the grafts. Fix this by setting the pointers to NULL after freeing the resources.

Similar to previous issues around doing way too much verification at loading
time, checking whether the object index chunk is monotonic is better left for
git-fsck instead of every single time we want to look at something in the
repository.

As midx files grow, this starts taking more and more times. As an example, I
went looking for this because it's taking about 1.5s to do a single object
lookup in a repository that's ended up with a 7G multi-pack-index file.

Similar to a previous change where we had to change the casting when loading the
index file, we also need to make sure we don't restrict the numbers to 32-bit
when looking up objects in packfiles.

This was done about three years ago in git itself, but we never got he update in
this library.

These chunks work like extensions where it's fine not to know what one means. We
can skip over it and keep processing the file instead of erroring out.

PR #5712 predates several refactorings to move the utility code into a
more general purpose codebase. Update to reflect the refactorings.

Fixes #5598

In several circumstances, we get bug reports about things that happen in
situations where the environment is quite limited with regards to
available memory. While it's expected that functionality will fail if
memory allocations fail, the assumption is that we should do so in a
controlled way. Most importantly, we do not want to crash hard due to
e.g. accessing NULL pointers.

Naturally, it is quite hard to debug such situations. But since our
addition of pluggable allocators, we are able to implement allocators
that fail in deterministic ways, e.g. after a certain amount of bytes
has been allocated. This commit does exactly that.

To be able to properly keep track of the amount of bytes currently
allocated, allocated pointers contain tracking information. This
tracking information is currently limited to the number of bytes
allocated, so that we can correctly replenish them on calling `free` on
the pointer. In the future, it would be feasible to extend the tracked
information even further, e.g. by adding information about file and line
where the allocation has been performed. As this introduced some
overhead to allocations though, only information essential to limited
allocations is currently tracked.

Monsters.

Not all systems have poll(2); emulate it with select(2).

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.

Now that we've reduced the usage of GIT_THREADSTATE, remove it entirely
in favor of git_threadstate_get().

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.

The `depth` field is suitable to specify unshallowing; provide an enum
to aide in specifying the `unshallow` value.

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.

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.

Depth of `0` should indicate full depth. Disallow negative values (they
may have a future meaning) and use `0` as the default.

Don't mix parsing by hand and using `git_parse` to parse.

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.

Looks like a double-free here.

... otherwise git_tree__parse_raw() will fail to obtain
the correct oid size, which causes the entire parse to fail.

Teach the smart transport more about oid types, instead of assuming SHA1.

The opt mechanism isn't _really_ meant to be for feature flags, and it's
weird to feature flag shallow / unshallow at all.

When the programdata path is missing, ensure that we pass down the
`GIT_ENOTFOUND` error to the caller instead of converting it to a
generic `-1`.