feat: Allow options to have longer names (#45626)

As part of the issue platform policy layer I'm generating option names
programatically. Some of these are going slightly over the 64 char
limit. Just increasing this to 128 to avoid running into it.

This is a safe database operation since Postgres 9.2
https://www.postgresql.org/docs/9.2/release-9-2.html#AEN114949

> Increasing the length limit for a varchar or varbit column, or
removing the limit altogether, no longer requires a table rewrite.
Similarly, increasing the allowable precision of a numeric column, or
changing a column from constrained numeric to unconstrained numeric, no
longer requires a table rewrite. Table rewrites are also avoided in
similar cases involving the interval, timestamp, and timestamptz types.

migrations_lockfile.txt

@@ -6,5 +6,5 @@ To resolve this, rebase against latest master and regenerate your migration. Thi
 will then be regenerated, and you should be able to merge without conflicts.
 
 nodestore: 0002_nodestore_no_dictfield
-sentry: 0375_remove_nullable_from_field
+sentry: 0376_longer_option_names
 social_auth: 0001_initial

src/sentry/migrations/0376_longer_option_names.py

@@ -0,0 +1,31 @@
+# Generated by Django 2.2.28 on 2023-03-10 21:18
+
+from django.db import migrations, models
+
+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. For
+    # the most part, 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 dangerous:
+    # - Large data migrations. Typically we want these to be run manually by ops 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
+    #   have ops run this and not block the deploy. Note that while adding an index is a schema
+    #   change, it's completely safe to run the operation after the code has deployed.
+    is_dangerous = False
+
+    dependencies = [
+        ("sentry", "0375_remove_nullable_from_field"),
+    ]
+
+    operations = [
+        migrations.AlterField(
+            model_name="option",
+            name="key",
+            field=models.CharField(max_length=128, unique=True),
+        ),
+    ]

src/sentry/models/options/option.py

@@ -17,7 +17,7 @@ class Option(Model):  # type: ignore
 
     __include_in_export__ = True
 
-    key = models.CharField(max_length=64, unique=True)
+    key = models.CharField(max_length=128, unique=True)
     value = PickledObjectField()
     last_updated = models.DateTimeField(default=timezone.now)
 

src/sentry/options/manager.py

@@ -218,8 +218,8 @@ class OptionsManager:
     ):
         assert key not in self.registry, "Option already registered: %r" % key
 
-        if len(key) > 64:
-            raise ValueError("Option key has max length of 64 characters")
+        if len(key) > 128:
+            raise ValueError("Option key has max length of 128 characters")
 
         # If our default is a callable, execute it to
         # see what value is returns, so we can use that to derive the type