We had two major problems with our new pre-upgrade flows:


We were running the pre-upgrade steps after the initial Evolver

   checks, which determine if an upgrade is required. This broke

   upgrades for oauth2_provider, since we couldn't reset the migration

   state early enough.


We weren't running these steps on new installations when using

manage.py createdb, so we never inserted the fake oauth2_provider

   migrations on any new development databases. This caused persisted

   system check failures on new installs. We did, however, run these on

rb-site install.


This change addresses both issues. We now unconditionally run the

install steps in all cases, and we
At this point, these are no longer simply "upgrade" steps. They're

state setup/migration steps. So we may want to revisit some of the

naming and where this all lives. For now, though, this gets us through

the biggest of upgrade woes.

Successfully upgraded reviews.reviewboard.org with this change.
Tested creating new databases via manage.py createdb, and tested

upgrading.
New databases no longer had warnings about missing migrations.
Existing databases from pre-5.0 could be upgraded.
Existing databases from 5.0 correctly stated that an upgrade was

not required.