feat(seer-infra-telemetry): Implement per-customer SA generation & deletion for GCP integrations

[shashjar]

PR 4/4 for CW-1691

Implements the GCP IAM API calls necessary for creating and deleting per-customer service accounts in the sentry-connectors GCP project, as part of the GCP MCP org-level integration setup and teardown logic. The SA email, when generated, is stored in OrganizationIntegration.config upon integration installation so that Seer can use it for SA impersonation.

https://app.notion.com/p/sentry/GCP-MCP-Org-Level-Integration-39f8b10e4b5d8030ba01cd62373641df

[sentry-warden]

Race condition in GCP service account creation causes IntegrityError

GcpServiceAccount.objects.create() is vulnerable to a race condition: concurrent pipeline requests for the same org will crash with IntegrityError due to unique=True on organization_id, and may leave orphaned GCP service accounts.

Evidence

• GcpServiceAccount.organization_id has unique=True in the model definition.
• generate_sentry_sa checks filter(...).first() for an existing record, then calls the external GCP IAM API to create a service account, then calls .create().
• The gap between the filter check and the .create() is not atomic, so concurrent pipeline requests for the same organization can both pass the existence check.
• The second .create() raises IntegrityError, and because IntegrityError is not caught by the existing except IntegrationError / except RequestException blocks, it propagates uncaught.
• The GCP service account created by the losing request becomes orphaned since it has no corresponding database record.

_{Identified by Warden · sentry-backend-bugs · WGJ-SRT}

[sentry-warden]

delete_sentry_sa removes DB record even when GCP delete fails

When the GCP IAM API returns a non-404 error, delete_sentry_sa logs the failure but still deletes the local GcpServiceAccount record, leaking the service account in GCP because Sentry no longer tracks it.

Evidence

• delete_sentry_sa in client.py calls session.delete(url) against the GCP IAM API.
• For 404 responses it logs a warning; for any other non-ok response it logs an error.
• After the if/elif block, execution falls through and unconditionally calls GcpServiceAccount.objects.filter(organization_id=org_id).delete().
• If GCP returns 500, 429, or 403, the SA still exists in GCP but Sentry's record is removed.
• On re-installation generate_sentry_sa finds no existing record and creates a new SA, leaving the old one orphaned in GCP.

_{Identified by Warden · sentry-backend-bugs · ELX-43G}