Investigate whether we can avoid locking `packed-refs` during access checks
Whenever a reference is about to be deleted, Git needs to lock both the loose reference and the packed-refs
file. In large repositories with lots of activity this can lead to lock contention, as multiple RPCs may want to lock the file at the same time.
This lock contention is aggravated by the fact that our access checks run while the reference is locked already:
- When serving pushes they are executed during
prepared
state of the reference-transaction hook. - In the Operations service, we manually execute the access checks after moving git-update-ref(1) into prepared state.
Given that access checks may take seconds or even dozens of seconds to finish, this means that the window during which the file stays locked is potentially very long. The result is thus that we often see this RPC fail.
We should investigate whether it is possible to perform the access checks with the packed-refs
file still unlocked.