Stop team label processor from reacting to gitlab bot events

What does this MR do and why?

Addresses the 2nd part of the bug described in #1126 (comment 1103836787)

Closes #1126 (closed) closes #1130 (closed)

My investigation with gitlab-org/gitlab#374098 (closed) receiving duplicated section and devops labels is the following:

By looking at the resource_label_events api response, the following label events happened first:

• developer added group::foundations and maintenance::refactor labels, at the exact time stamp, which tells me they were added with the /label quick action in the comment 2022-09-16T12:29:02.039Z:

{
    "id": 186578521,
    "user": {
       ...
      "username": "pgascouvaillancourt",
    },
    "created_at": "2022-09-16T12:29:02.039Z",
     ...
    "label": {
      ...
      "name": "group::foundations",
    },
    "action": "add"
  },
  {
    "id": 186578522,
    "user": {
      ...
      "username": "pgascouvaillancourt",
    },
    "created_at": "2022-09-16T12:29:02.039Z",
     ...
    "label": {
      "name": "maintenance::refactor",
       ...
    },
    "action": "add"
  },

• Because maintenance::refactor triggered a type label automation to add type::maintenance, the gitlab-bot went ahead and added the type label, before the section and devops labels were added, at 2022-09-16T12:29:02.816Z":

{
    "id": 186578530,
    "user": {
      ...
      "username": "gitlab-bot",
    },
    "created_at": "2022-09-16T12:29:02.816Z",
    ...
    "label": {
      ...
      "name": "type::maintenance",
    },
    "action": "add"
  },

• Due to the above 2 label update events both occurred when devops and section labels are missing, they subsequently both invoked the team label inference processor to apply the missing scoped labels, first time at 2022-09-16T12:29:03.468Z, then at 2022-09-16T12:29:03.488Z, just milliseconds apart:

{
    "id": 186578543,
    "user": {
       ...
      "username": "gitlab-bot",
    },
    "created_at": "2022-09-16T12:29:03.468Z",
     ...
    "label": {
      ...
      "name": "devops::ecosystem",
    },
    "action": "add"
  },
  {
    "id": 186578544,
    "user": {
      "username": "gitlab-bot",
       ...
    },
    "created_at": "2022-09-16T12:29:03.468Z",
    "label": {
       ...
      "name": "section::dev",
    },
    "action": "add"
  },
  {
    "id": 186578545,
    "user": {
      "username": "gitlab-bot",
    },
    "created_at": "2022-09-16T12:29:03.488Z",
    "label": {
      "name": "devops::ecosystem",
       ...
    },
    "action": "add"
  },
  {
    "id": 186578546,
    "user": {
      ...
      "username": "gitlab-bot",
    },
    "created_at": "2022-09-16T12:29:03.488Z",
    "label": {
      "name": "section::dev",
      ...
    },
    "action": "add"
  }

The solution is to just let the team label inference processor skip the gitlab bot event, so this scenario will no longer happen.

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-with-a-dry-run on how to perform dry-runs.

Action items

• (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