git: Fix object pool spec checking for wrong reference

What does this MR do and why?

When fetching from a source repository into its object pool to update it, then we fetch all refs into the "origin" remote namespace via the refspec "+refs/:refs/remotes/origin/". In hindsight, using this namespace doesn't make a lot of sense and we should've instead used a better namespace like "refs/pool/" or something like that to better highlight that it's not a normal remote at all but special to how our object pools work. With this namespacing, "refs/heads/master" would thus end up as "refs/remotes/origin/heads/master". Replicating the "heads" component is required such that we can also easily fetch tags without clobbering the parent's tags.

So while there shouldn't be any refs like "refs/remotes/origin/master", one of our object pool specs explicitly checks for that reference and in fact finds it. As it turns out, this is a bug in Gitaly's current implementation: besides using above refspec, Gitaly also implicitly uses the default refspec as created by git-remote(1). So in essence, we fetch branches twice.

The bug will be fixed implicitly by Gitaly converting to use in-memory remotes, where there is no more on-disk remote when using object pools. Given that we check for the wrong reference right now, this change will break the spec and we end up not finding the reference in question anymore.

Fix this by instead checking "refs/remotes/origin/heads/master".

Blocks gitaly!4038 (merged)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.