Swap to http integration requests for prometheus alerting

What does this MR do and why?

Broader context:

• We have a feature allowing users to configure webhooks in gitlab which accept alerts from third party monitoring tools
  • alert integrations docs
  • These integrations have two types: one for alerts from prometheus and one for generic alerts from any source
• When implemented, prometheus integrations piggy-backed on the Integrations::Prometheus model, while generic integrations were built using AlertManagement::HttpIntegrations. But the primary use-case of Integrations::Prometheus was deprecated & removed from the product, so we need to detangle the code in order to remove that code.
  • As of !120197 (merged), the backend is fully updated to use AlertManagement::HttpIntegrations for both prometheus and generic alert integrations
• The plan is to sunset the alert management features in future as well 🤷

This MR:

• Removes all usage of the graphql queries/mutations specific to prometheus integrations, replacing them with the generic http integration mutations/queries
  • existing integrations were migrated & kept in sync since !119847 (merged), so there will be no downtime or additional action needed to switch over
• Consolidates features of alert integrations and prometheus integrations, including:
  • add support for custom names for prometheus integrations
  • add support for custom mapping for prometheus integrations (supported on backend since !120055 (merged))

References

• Allow Prometheus' metrics dashboard and incomin... (#338838 - closed)

Screenshots or screen recordings

Run-through for HTTP integrations	Run-through for Prometheus integrations
new_http_integration	new_prometheus_integration

How to set up and validate locally

For each of HTTP & prometheus, all of these operations should work:

• create integration (in project, Settings > Monitor > Alerts > Current integrations > "Add new integration")
  • without custom mapping (just leave those fields blank)
    • in free tier, only one of each type should be allowed
    • in premium+, multiple of each type are allowed
  • with custom mapping (premium only)
    • HTTP sample payload:

    {
      "title": "HTTP unmapped title sample",
      "mapped_title": "HTTP mapped title sample"
    }

    • PROMETHEUS sample payload:

    {
      "generatorURL": "http://host?g0.expr=up",
      "startsAt": "2025-06-10T11:22:40Z",
      "status": "firing",
      "labels": {
        "mapped_title": "Prometheus mapped title sample"
      },
      "annotations": {
        "title": "Prometheus unmapped title sample"
      }
    }

• read integration (see integration in list with token & url)
• update integration (⚙ > Configure details to change name, deactivate)
• reset token (⚙ > View credentials)
• send & view test alert (⚙ > Send test alert)
  • without custom mapping

    {
      "title": "HTTP unmapped title",
    }

    {
      "version" : "4",
      "groupKey": null,
      "status": "firing",
      "receiver": "",
      "groupLabels": {},
      "commonLabels": {},
      "commonAnnotations": {},
      "externalURL": "",
      "alerts": [{
        "generatorURL": "http://host?g0.expr=up",
        "startsAt": "2025-06-10T12:22:40Z",
        "status": "firing",
        "annotations": {
          "title": "Prometheus unmapped title"
        }
      }]
    }

  • with custom mapping (can use same payload for both)
  • generic http sample payload:

    {
      "mapped_title": "HTTP mapped title"
    }

  • prometheus sample payload:

    {
      "version" : "4",
      "groupKey": null,
      "status": "firing",
      "receiver": "",
      "groupLabels": {},
      "commonLabels": {},
      "commonAnnotations": {},
      "externalURL": "",
      "alerts": [{
        "generatorURL": "http://host?g0.expr=up",
        "startsAt": "2025-06-10T13:22:40Z",
        "status": "firing",
        "labels": {
          "mapped_title": "Prometheus mapped title"
        },
        "annotations": {}
      }]
    }

• delete integration (click 🗑️)

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.