Fix Elasticsearch race condition during initial repo push

What does this MR do?

Upon initial repository push we run ElasticCommitIndexerWorker from inside GitPushService. If the repo is very big, and/or someone does another push to master before the first indexing can happen, we end up not indexing the initial one.

Unfortunately I could not get to the bottom of WHY the second indexing operation shadows the first one, and I don't have any theories as to why this happens, so I'm focusing on making the scenario much less likely to happen in this MR

What we do is, if the push is for a new repo, we lock the repo so GitPushService will refuse to send pushes for indexing in the same manner as we did in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/9478

This should not result in any subsequent push being lost, as we also make sure we change the parameters so that when ElasticCommitIndexerWorker runs it pulls the last existing commit at that time

What are the relevant issue numbers?

https://gitlab.com/gitlab-org/gitlab-ee/issues/8013

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated via this MR
• Documentation reviewed by technical writer or follow-up review issue created
• Tests added for this feature/bug
• Tested in all supported browsers
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides
• Conforms to the database guides
• Link to e2e tests MR added if this MR has Requires e2e tests label. See the Test Planning Process.
• EE specific content should be in the top level /ee folder
• For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan?
• Security reports checked/validated by reviewer

Closes #8013 (closed)