Metrics for tracking pipeline statuses after resolve dependency workflow

What does this MR do and why?

This MR adds an internal tracking event generate_resolve_dependency_bump_pipeline for tracking the status of the pipeline finished after the changes made by the resolve dependency workflow. This helps us in determining that in how many cases did the pipeline turned green after the workflow made changes on the MR.

References

• Issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/604832 (Implement metrics to track success of the Dependency Bump Breaking Changes Resolution flow)
• Parent epic: https://gitlab.com/groups/gitlab-org/-/work_items/17884 (Resolve breaking changes from dependency bumps)

Generated metric key paths:

• counts.count_total_generate_resolve_dependency_bump_pipeline (all)
• counts.count_total_generate_resolve_dependency_bump_pipeline_monthly (28d)
• counts.count_total_generate_resolve_dependency_bump_pipeline_weekly (7d)

How to set up and validate locally

Steps performed, in order:

1. You need to have a group with GitLab Ultimate license and Duo seats, you can clone the project https://gitlab.com/compliance-group-testing-and-demos/team-testing-subgroup/hraghuvanshi/dep-bump-test-all/product-filter-api in that group.

2. Enable the feature flag in a rails console:

   Feature.enable(:enable_dependency_bump_breaking_changes_pipeline_tracking)

3. Confirm the flow is available for the project. In a rails console, this must return true:

   project.duo_dependency_bump_breaking_changes_available?

4. Create a branch named dependency-management/express-4.x whose head commit is a real breaking dependency bump. The one used was "Bump express from 4.21.2 to 4.22.0", touching package.json and package-lock.json.

5. Open a merge request from that branch, authored by the "GitLab Dependency Management" service account. The worker matches the author using the authored_by_dependency_bump_service_account scope, so a merge request authored by a normal user is not picked up.

6. Push the branch. No manual step is needed to start the flow: the pushed branch produces a pipeline that fails because of the breaking change, that failing pipeline publishes Ci::PipelineFinishedEvent, the event store filter matches it, and DependencyManagement::SecurityUpdate::TriggerResolveDependencyBumpWorkflowWorker creates a resolve_dependency_bump workflow. If you would rather force it, call that worker's handle_event directly with the event, but it is not necessary.

7. In a second terminal, watch the event:

   rails runner scripts/internal_events/monitor.rb generate_resolve_dependency_bump_pipeline

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.