feat(preprod): Add SizeAnalysisSubscription as a DataSource

[chromy]

Add SizeAnalysisSubscription model as a DataSource for size monitors. Since we're pushing
size data from the monolith we know when we need to evaluate detectors and so can avoid
polling - however this means we also need our own subscription type rather than re-using
QuerySubscription.

PRs:

• feat(preprod): Add SizeAnalysisSubscription as a DataSource #108172 Add SizeAnalysisSubscription (this PR)
• feat(preprod): Add Size Analysis detector #108208 Add size_analysis detector
• feat(preprod): Hook size analysis detector to diff #108209 Hook size analysis detector to diff
• feat(preprod): Add new issue type to frontend #108210 Add new issue type to frontend
• feat(preprod): Add size monitor UI #108211 Add size monitor UI

[github-actions]

This PR has a migration; here is the generated SQL for src/sentry/preprod/migrations/0027_size_analysis_subscription.py

for 0027_size_analysis_subscription in preprod

--
-- Create model SizeAnalysisSubscription
--
CREATE TABLE "sentry_sizeanalysissubscription" ("id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY, "date_updated" timestamp with time zone NOT NULL, "date_added" timestamp with time zone NOT NULL, "project_id" bigint NOT NULL);
ALTER TABLE "sentry_sizeanalysissubscription" ADD CONSTRAINT "sentry_sizeanalysiss_project_id_41e3355e_fk_sentry_pr" FOREIGN KEY ("project_id") REFERENCES "sentry_project" ("id") DEFERRABLE INITIALLY DEFERRED NOT VALID;
ALTER TABLE "sentry_sizeanalysissubscription" VALIDATE CONSTRAINT "sentry_sizeanalysiss_project_id_41e3355e_fk_sentry_pr";
CREATE INDEX CONCURRENTLY "sentry_sizeanalysissubscription_project_id_41e3355e" ON "sentry_sizeanalysissubscription" ("project_id");

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[NicoHinderling]

is there not some other models file for subscription / data source handlers that this should live in instead?

[wedamija]

Could you explain how data is coming in here? Is this doing something similar to metric alerts, where a query is running in snuba on a regular schedule and you're then processing the results?

[chromy]

Could you explain how data is coming in here? Is this doing something similar to metric alerts, where a query is running in snuba on a regular schedule and you're then processing the results?

@wedamija Sorry! Yeah was not the best description. No, the idea was that compare_preprod_artifact_size_analysis would call through to process_data_packet on each new data point. I wrote a bit more here: https://www.notion.so/sentry/Size-Monitors-3068b10e4b5d805ca57de084d1b4eba6

[saponifi3d]

Are you planning to add any more to this model or is it just for the data source relationship?

If it's just for the data source, we could also omit this class if you wanted. Since the relationship is based on the project_id, we could just directly lookup the detectors w/o a data source and reduce the number of rows needed in the DB for these detectors. The only benefit for this relationship is some added caching layers for looking up detectors (it's only a 3min TTL, so probably wouldn't help too much for these detectors).

if you wanted to omit this class / the data source entirely, you could just create the Detector model, select the detectors by type + project_id, and then run process_detectors instead of process_data_packet.

[chromy]

If we can get away without even better! I'll draft this one and go straight for #108208