Fetch issue labels from api instead of from events

What does this MR do and why?

Describe in detail what your merge request does and why.

Resolves a bug in the broken master label automation to check label via issue api, instead of from the triggering event, as mentioned in #1196 (closed):

despite of waiting for 5 minutes to add the ping, it's still relying only the original event attributes from 5 minutes ago to decide whether labels are missing or not -- what should happen is that the BrokenMasterLabelNudgerJob should just directly make a request to the issue object and check the labels, to ensure the result is reflecting the latest.

closes #1174 (closed)

before change

processor job relies on the triggering event to verify labels, so the processor job will not know whether labels have been updated even after waiting for 5 minutes.

after change

both processor and processor jobs make an API call to the issue to verify labels, this ensures that the processor job will pick up any changes to the labels after 5 minutes and will not ping the user if concrete root cause labels have been added by then.

Closes #1196 (closed)

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