ref: drop table sentry_sentryfunction (#70852)

followup to #70750

<!-- Describe your PR here. -->

migrations_lockfile.txt

@@ -9,5 +9,5 @@ feedback: 0004_index_together
 hybridcloud: 0016_add_control_cacheversion
 nodestore: 0002_nodestore_no_dictfield
 replays: 0004_index_together
-sentry: 0721_delete_sentryfunctions
+sentry: 0722_drop_sentryfunctions
 social_auth: 0002_default_auto_field

src/sentry/migrations/0722_drop_sentryfunctions.py

@@ -0,0 +1,33 @@
+# Generated by Django 5.0.4 on 2024-05-14 12:52
+
+from django.db import migrations
+
+from sentry.new_migrations.migrations import CheckedMigration
+
+
+class Migration(CheckedMigration):
+    # This flag is used to mark that a migration shouldn't be automatically run in production.
+    # This should only be used for operations where it's safe to run the migration after your
+    # code has deployed. So this should not be used for most operations that alter the schema
+    # of a table.
+    # Here are some things that make sense to mark as post deployment:
+    # - Large data migrations. Typically we want these to be run manually so that they can be
+    #   monitored and not block the deploy for a long period of time while they run.
+    # - Adding indexes to large tables. Since this can take a long time, we'd generally prefer to
+    #   run this outside deployments so that we don't block them. Note that while adding an index
+    #   is a schema change, it's completely safe to run the operation after the code has deployed.
+    # Once deployed, run these manually via: https://develop.sentry.dev/database-migrations/#migration-deployment
+
+    is_post_deployment = False
+
+    dependencies = [
+        ("sentry", "0721_delete_sentryfunctions"),
+    ]
+
+    operations = [
+        migrations.RunSQL(
+            'DROP TABLE IF EXISTS "sentry_sentryfunction";',
+            reverse_sql="CREATE TABLE sentry_sentryfunction (fake_col int)",
+            hints={"tables": ["sentry_sentryfunction"]},
+        )
+    ]