Remove Gitaly as responsible team for when gitlab.com is overloaded

What does this MR do and why?

Currently the Gitaly is held responsible for when gitlab.com is overloaded. While Gitaly does return errors when gitlab.com is overloaded, this is considered normal behavior from Gitaly's point of view and even a positive thing.

If Gitaly were to allow unbounded traffic to its nodes, a more catastrophic failure could occur. Backpressure in the form of concurrency limits and rate limiting is meant to protect the entire fleet.

Instead, the team who should be pinged about gitlab.com being overloaded should be the team in the best position to debug and find the client cause of the load.

Expected impact & dry-runs

These are strongly recommended to assist reviewers and reduce the time to merge your change.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

• If adding environment variables for reactive processors, update config/triage-web.yaml and .gitlab/ci/triage-web.yml
• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels =>
  • Engineering week-in-review