Fetch pipeline from the API when checking for merge results pipeline

Context

Follow-up of !2997 (merged).

I'm testing this processor in https://gitlab.com/gitlab-org/quality/engineering-productivity/triage-ops-playground/-/merge_requests/17, and I noticed some issues with the ref field of the pipeline webhook event (see the investigation and the follow-up product issue).

We made an MR to add extra ref fields in the pipeline webhook event, but until this MR is merged, we need a workaround.

What does this MR do and why?

Use the pipeline API resource instead of the pipeline webhook event when verifying the pipeline is a merged results pipeline.

The pipeline ref attribute in the pipeline webhook event is the merge request ref, which is the branch name.

We need the pipeline ref, which has a more precise format, to determine whether the pipeline ran a merged results pipeline.

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