feat(db): Add dates related to builds in the AppStore Connect table (#27415)

Added two additional dates to eventually provide more context 
to users about the current state of their AppStore Connect 
integration.

Relates to NATIVE-89

migrations_lockfile.txt

@@ -7,5 +7,5 @@ will then be regenerated, and you should be able to merge without conflicts.
 
 jira_ac: 0001_initial
 nodestore: 0002_nodestore_no_dictfield
-sentry: 0220_add_current_release_version_group_resolution
+sentry: 0221_add_appconnect_upload_dates
 social_auth: 0001_initial

src/sentry/lang/native/appconnect.py

@@ -92,7 +92,7 @@ class AppStoreConnectConfig:
     # easily to retrieve via an HTTP request to iTunes.
     itunesPersonId: str
 
-    # The iTuness session cookie.
+    # The iTunes session cookie.
     #
     # Loading this cookie into ``requests.Session`` (see
     # ``sentry.utils.appleconnect.itunes_connect.load_session_cookie``) will allow this

src/sentry/migrations/0221_add_appconnect_upload_dates.py

@@ -0,0 +1,43 @@
+# Generated by Django 1.11.29 on 2021-07-14 17:01
+
+import django.utils.timezone
+from django.db import migrations, models
+
+
+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.
+    # You'll also usually want to set this to `False` if you're writing a data
+    # migration, since we don't want the entire migration to run in one long-running
+    # transaction.
+    atomic = True
+
+    dependencies = [
+        ("sentry", "0220_add_current_release_version_group_resolution"),
+    ]
+
+    operations = [
+        migrations.AddField(
+            model_name="appconnectbuild",
+            name="first_seen",
+            field=models.DateTimeField(default=django.utils.timezone.now),
+        ),
+        migrations.AddField(
+            model_name="appconnectbuild",
+            name="uploaded_to_appstore",
+            field=models.DateTimeField(default=django.utils.timezone.now),
+        ),
+    ]

src/sentry/models/appconnectbuilds.py

@@ -5,6 +5,7 @@ need to keep track of which builds have already been downloaded.
 """
 
 from django.db import models
+from django.utils import timezone
 
 from sentry.db.models import FlexibleForeignKey, Model
 
@@ -49,6 +50,12 @@ class AppConnectBuild(Model):
     # Whether we already fetched the dSYMs for this build.
     fetched = models.BooleanField(default=False)
 
+    # When the build was uploaded to AppStore.
+    uploaded_to_appstore = models.DateTimeField(default=timezone.now)
+
+    # When sentry first saw the build on AppStore Connect.
+    first_seen = models.DateTimeField(default=timezone.now)
+
     class Meta:
         db_table = "sentry_appconnectbuild"
         app_label = "sentry"