fix(metric_alerts): Migrate `error_rate()` SnubaQuery rows to `failure_rate()` (#19291)

After https://github.com/getsentry/sentry/pull/19093 any rows that existed with `error_rate` now
fail. This migrates them across. This only affects test data so far, but we're still better off
correcting it so that we don't see errors in sentry.

Fixes SENTRY-GR7
Fixes SENTRY-GR6

migrations_lockfile.txt

@@ -10,7 +10,7 @@ auth: 0008_alter_user_username_max_length
 contenttypes: 0002_remove_content_type_name
 jira_ac: 0001_initial
 nodestore: 0001_initial
-sentry: 0084_exported_data_blobs
+sentry: 0085_fix_error_rate_snuba_query
 sessions: 0001_initial
 sites: 0002_alter_domain_unique
 social_auth: 0001_initial

src/sentry/migrations/0085_fix_error_rate_snuba_query.py

@@ -0,0 +1,41 @@
+# -*- coding: utf-8 -*-
+# Generated by Django 1.11.29 on 2020-06-10 22:11
+from __future__ import unicode_literals
+
+from django.db import migrations
+
+from sentry.utils.query import RangeQuerySetWrapperWithProgressBar
+
+
+def fix_error_rate_snuba_queries(apps, schema_editor):
+    SnubaQuery = apps.get_model("sentry", "SnubaQuery")
+    for snuba_query in RangeQuerySetWrapperWithProgressBar(
+        SnubaQuery.objects.filter(aggregate="error_rate()")
+    ):
+        snuba_query.aggregate = "failure_rate()"
+        snuba_query.save()
+
+
+class Migration(migrations.Migration):
+    # This flag is used to mark that a migration shouldn't be automatically run in
+    # production. We set this to True for operations that we think are risky and want
+    # someone from ops to run manually and monitor.
+    # General advice is that if in doubt, mark your migration as `is_dangerous`.
+    # Some things you should always mark as dangerous:
+    # - Large data migrations. Typically we want these to be run manually by ops so that
+    #   they can be monitored. Since data migrations will now hold a transaction open
+    #   this is even more important.
+    # - Adding columns to highly active tables, even ones that are NULL.
+    is_dangerous = False
+
+    # This flag is used to decide whether to run this migration in a transaction or not.
+    # By default we prefer to run in a transaction, but for migrations where you want
+    # to `CREATE INDEX CONCURRENTLY` this needs to be set to False. Typically you'll
+    # want to create an index concurrently when adding one to an existing table.
+    atomic = False
+
+    dependencies = [("sentry", "0084_exported_data_blobs")]
+
+    operations = [
+        migrations.RunPython(fix_error_rate_snuba_queries, reverse_code=migrations.RunPython.noop)
+    ]