Right now, we first load the packed refs cache and only afterwards load the
loose references. This is susceptible to a race when the loose ref is being
migrated to a packed cache by e.g. git-pack-refs(1):

                libgit2                             git-pack-refs

   1. We load the packed ref, which
      does not yet have the migrated
      reference.

                                      2. git-pack-refs updates the packed ref
                                         file to have the migrated ref.

                                      3. git-pack-refs deletes the old loose
                                         ref.

   4. We look up the loose ref.

So we now do not find the reference at all and will never iterate over it.

Fix the issue by reversing the order: instead of first loading the packed refs,
we will now look up the loose reference first. If it has already been deleted,
then it must already be present in the packed-refs by definition, as git.git
will only delete the reference after updating the packed refs file.

Right now, loading loose refs has the side-effect of setting the
`PACKREF_SHADOWED` flag for references that exist both in the loose and the
packed refs. Because of this, we are force do first look up packed refs and only
afterwards loading the packed refs. This is susceptible to a race, though, when
refs are being repacked: when first loading the packed cache, then it may not
yet have the migrated loose ref. But when now trying to look up the loose
reference afterwards, then it may already have been migrated. Thus, we would
fail to find this reference in this scenario.

Remove this ordering dependency to allow fixing the above race. Instead of
setting the flag when loading loose refs, we will now instead set it lazily when
iterating over the loose refs. This even has the added benefit of not requiring
us to lock the packed refs cache, as we already have an owned copy of it.

When creating a new iterator, we eagerly load loose refs but only lazily create
a copy of packed refs. The lazy load only happens as soon as we have iterated
over all loose refs, opening up a potentially wide window for races. This
may lead to an inconsistent view e.g. when the caller decides to reload packed
references somewhen between iterating the loose refs, which is unexpected.

Fix the issue by eagerly copying the sorted cache. Note that right now, we are
heavily dependent on ordering here: we first need to reload packed refs, then we
have to load loose refs and only as a last step are we allowed to copy the
cache. This is because loading loose refs has the side-effect of setting the
`PACKED_SHADOWED` flag in the packed refs cache, which we require to avoid
outputting packed refs that already exist as loose refs.

Refactor the error handling in `refdb_fs_backend__iterator` to always return the
correct error code returned by the failing function.

When repacking references, git.git will first update the packed refs and only
afterwards delete any existing loose references that have now been moved to the
new packed refs file. Due to this, there is a potential for racing if one first
reads the packfile (which has not been updated yet) and only then trying to read
the loose reference (which has just been deleted). In this case, one will
incorrectly fail to lookup the reference and it will be reported as missing.
Naturally, this is exactly what we've been doing in `refdb_fs_backend__exists`.

Fix the race by reversing the lookup: we will now first check if the loose
reference exists and only afterwards refresh the packed file.

Move to the `git_error` name in the internal API for error-related
functions.

Update internal usage to use the `git_reference` names for constants.

The function `refdb_reflog_fs__delete` uses the `if (!error && foobar())`
pattern of checking, where error conditions are being checked by following calls
to different code. This does not match our current style, where the call-site of
a function is usually directly responsible for checking the return value.

Convert the function to use `if ((error = foobar()) < 0) goto out;` style. Note
that this changes the code flow a bit: previously, we were always trying to
delete empty reference hierarchies even if deleting the reflog entry has failed.
This wasn't much of a problem -- if deletion failed, the hierarchy will still
contain at least one file and thus the function call was an expensive no-op.
Now, we will only perform this deletion if we have successfully removed the
reflog.

Remove empty (sub-)directories when deleting refs