git: Fix object pool spec checking for wrong reference

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".

spec/lib/gitlab/git/object_pool_spec.rb

@@ -112,7 +112,7 @@ RSpec.describe Gitlab::Git::ObjectPool do
 
         subject.fetch
 
-        expect(subject.repository.commit_count('refs/remotes/origin/master')).to eq(commit_count)
+        expect(subject.repository.commit_count('refs/remotes/origin/heads/master')).to eq(commit_count)
         expect(subject.repository.commit(new_commit_id).id).to eq(new_commit_id)
       end
     end