Backport of "Trigger dep-bump resolution on merge request pipeline failures" to 19.2

What does this MR do and why?

Backport of Trigger dep-bump resolution on merge request pipeline failures to the 19.2 stable branch.

The dependency-bump breaking-change resolution flow was never triggered for merge-request pipeline failures. DependencyManagementSubscriptions#dependency_bump_mr_failure? filtered failed pipelines on pipeline.ref. For merge-request pipelines, ref is the internal MR ref (e.g. refs/merge-requests/7/head), not the source branch, so the dependency-management/ prefix check never matched and TriggerResolveDependencyBumpWorkflowWorker was never enqueued. Only failures on branch pipelines (whose ref is the source branch) got through.

This is the common case: projects that run CI on merge-request pipelines ($CI_PIPELINE_SOURCE == "merge_request_event") have passing branch pipelines and a failing MR pipeline, exactly the pipeline that was being filtered out. The workflow therefore never ran and the auto-generated dependency-bump MRs were left with broken pipelines.

The fix filters on pipeline.source_ref, which resolves to the MR source branch for merge-request pipelines and falls back to ref for branch pipelines, covering both pipeline types. It is a strict superset of the previous behaviour, so branch-pipeline failures continue to trigger as before.

Because the enable_dependency_bump_breaking_changes feature flag is on by default (beta), the broken behaviour is live in 19.2 for any project that enables the setting, so this fix is being backported.

Cherry-pick of merge commit dbb9b524117f4c2ec04fa67d25b14f01b1ae007a.

Related issue: #607851 (closed) Original bug: #606046 (closed)

MR acceptance checklist

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
• Required labels have been applied to this merge request
  • severity label and bug subtype labels (if applicable)
  • If this MR fixes a bug that affects customers, the customer label has been applied.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the e2e:test-on-omnibus-ee job has succeeded, or if it has failed, investigate the failures. If you determine the failures are unrelated, you may proceed.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).
• Once the backport has been merged, the commit changes will be automatically deployed to a release environment that can be used for manual validation. See after merging runbook for details.