search: see if we can remove the sync.Once optimization in gitCommitResolver.OID

[ijt]

It may no longer be necessary now that @slimsag has added a cache that serves the same purpose.

1. Add a benchmark that exercises gitCommitResolver.OID in an approximately realistic way, ideally by issuing some search queries.
2. Try removing gitCommitResolver.once and see if the perf is affected.

[slimsag]

I mentioned this in #3685 -- this isn't the right approach.

This is not possible without a significant undertaking. In order to verify this, we would need to vet or add benchmarks for every downstream consumer of this method: https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/cmd/frontend/graphqlbackend/git_commit.go#L86:29&tab=references

That is to say, it is not just search that exercises this codepath. Just benchmarking search queries is not enough to ensure removing gitCommitResolver.once is safe.

While we could vet and benchmark all of these downstream consumers, the time would be better spent refactoring code so that Zoekt hands us the indexed revision as part of search results so that we are not doing lazy OID resolution in the first place. I'm filing an issue detailing this.

[slimsag]

Closing in favor of https://github.com/sourcegraph/sourcegraph/issues/3750