Prevent errors from non-functional notify_post_receive endpoint

What does this MR do?

Update Gitlab-Shell to follow with the gl_repository migration plan, but disable the notify_post_receive endpoint for the moment, because is currently a no-op in Gitaly

Are there points in the code the reviewer needs to double check?

No

Why was this MR needed?

Follow with the migration plan to introduce the gl_repository variable https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/130#note_29135923 and prevent future errors from notify_post_receive until it makes sense to re-enable it.

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• API support added
• Tests
  • Added for this feature/bug
  • All builds are passing
• Conform by the merge request performance guides
• Conform by the style guides
• Branch has no merge conflicts with master (if it does - rebase it please)
• Squashed related commits together

/cc @jacobvosmaer-gitlab

changed milestone to %9.2

This is happening quite a bit on GitLab.com:

https://sentry.gitlap.com/gitlab/gitlabcom/issues/30485/activity/

Shall we aim to get this into 9.2.0?

/cc: @tim, @selfup

assigned to @stanhu

@stanhu ready to merge

assigned to @eReGeBe

assigned to @stanhu

resolved all discussions

approved this merge request

merged

mentioned in commit a9c1925d

mentioned in issue #32839 (closed)

This doesn't exactly look like a regression fix for %9.2 to me (please correct me if I'm wrong, @eReGeBe).

I'll pick this to 9-2-stable after we have three sign-offs, as in https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md#after-the-7th:

- [x] a release manager: @timothyandrew
- [x] the VP of Engineering: @stanhu
- [ ] an Engineering Lead: @DouweM

I think it is a regression from 9.2 (https://sentry.gitlap.com/gitlab/gitlabcom/issues/30485/activity/):

Picked into 9-2-stable, will go into 9.2.2.

mentioned in commit f50598f7

mentioned in issue #31015 (closed)