test_fixtures: Fix bug with run_db_migrations for test platform.

In this commit we are fixing a kinda serious un-noticed bug with
the way run_db_migrations worked for test db.
Basically run_db_migrations runs new migrations on db (dev or test).
When we talk about the dev platform this process is straight forward.
We have a single DB zulip which was once created and now has some data.
Introduction of new migration causes a schema change or does something
else but bottom line being we just migrate the zulip DB and stuff works
fine.

Now coming to zulip test db (zulip_test) situation is a bit complex
in comparision to dev db. Basically this is because we make use of
what we call zulip_test_template to make test fixture restoration
after tests run fast. Now before we introduced the performance
optimisation of just doing migrations when possible, introduction of
a migration would ideally result in provisioning do a full rebuild of
the test database. When that used to happen sequence of events used to
be something like this:
* Create a zulip_test db from zulip_test_base template (An absolute
basic schema holding)
* Migrate and populate the zulip_test db.
* Create/Re-create zulip_test_template from the latest zulip_test.

Now after we introduced just do migrations instead of full db rebuild
when possible, what used to happen was that zulip_test db got
successfully migrated but when test suites would run they would try to
create zulip_test from zulip_test_template (so that individual tests
don't affect each other on db level).
This is where the problem resides; zulip_test_template wasn't migrated
and we just scrapped zulip_test and re-created it using
zulip_test_template as a template and hence zulip_test will not hold the
latest schema.

This is what we fix in this commit.

zerver/lib/test_fixtures.py

@@ -26,18 +26,23 @@ def run_db_migrations(platform: str) -> None:
     if platform == 'dev':
         migration_status_file = 'migration_status_dev'
         settings = 'zproject.settings'
+        db_name = 'ZULIP_DB_NAME=zulip'
     elif platform == 'test':
         migration_status_file = 'migration_status_test'
         settings = 'zproject.test_settings'
+        db_name = 'ZULIP_DB_NAME=zulip_test_template'
 
     # We shell out to `manage.py` and pass `DJANGO_SETTINGS_MODULE` on
     # the command line rather than just calling the migration
     # functions, because Django doesn't support changing settings like
     # what the database is as runtime.
-    run(['env', ('DJANGO_SETTINGS_MODULE=%s' % settings), './manage.py',
-         'migrate', '--no-input'])
-    run(['env', ('DJANGO_SETTINGS_MODULE=%s' % settings), './manage.py',
-         'get_migration_status', '--output=%s' % (migration_status_file)])
+    # Also we export DB_NAME which is ignored by dev platform but
+    # recognised by test platform and used to migrate correct db.
+    run(['env', ('DJANGO_SETTINGS_MODULE=%s' % settings), db_name,
+         './manage.py', 'migrate', '--no-input'])
+    run(['env', ('DJANGO_SETTINGS_MODULE=%s' % settings), db_name,
+         './manage.py', 'get_migration_status',
+         '--output=%s' % (migration_status_file)])
 
 def run_generate_fixtures_if_required(use_force: bool=False) -> None:
     generate_fixtures_command = ['tools/setup/generate-fixtures']

zproject/test_settings.py

@@ -25,7 +25,7 @@ REALM_HOSTS = {}
 BACKEND_DATABASE_TEMPLATE = 'zulip_test_template'
 
 DATABASES["default"] = {
-    "NAME": "zulip_test",
+    "NAME": os.getenv("ZULIP_DB_NAME", "zulip_test"),
     "USER": "zulip_test",
     "PASSWORD": LOCAL_DATABASE_PASSWORD,
     "HOST": "localhost",