objectpool: Switch to use OptimizeRepository for pool repos
The equivalent to a housekeeping job for object pools is our
FetchIntoObjectPool RPC: it fetches all changes from the primary pool
member and then optimizes the repository. Its implementation is separate
from housekeeping.OptimizeRepository()
though which creates a world
where we have two parallel implementations of repository housekeeping,
which goes against our principle of a single source of truth.
More importantly though pool repositories may not only be optimized via FetchIntoObjectPool, but also via our nightly repository housekeeping job. So we already use both implementations to pack a repository. And sure enough, they had some subtle differences already like delta islands not being the same. Furthermore, OptimizeRepository is doing some things like keeping commit-graphs up to date that FetchIntoObjectPool doesn't.
Unify the infrastructure so that we only have a one maintenance strategy to worry about: OptimizeRepository. This has multiple benefits:
- We avoid any future divergence in behaviour.
- We have less code to worry about.
- Nightly maintenance and on-demand maintenance use the same code
paths.
- Commit-graphs are kept up to date again, which is something that
has been broken in object pools for quite a while.
- We avoid doing needless work when there is not much to be done
thanks to the heuristisc of OptimizeRepository.
- We avoid running repository maintenance concurrently on the same
pool repository given that OptimizeRepository exits early when it
sees a concurrent call to the same repository.
The new strategy is guarded by a feature flag for the time being.
Fixes #4338 (closed).
Part of #2359 (moved).