Update upgrade process: separate schema and data restoration

[h-artzi]

Is your feature request related to a problem? Please describe.

I would like to see an upgrade process that separates the loading of the schema and the data because currently, the upgrade process reorders the triggers.

Background:
After a pg_dump and pg_restore, all foreign key constraints are placed in alphabetical order by their name. Then converted into triggers RI_ConstraintTrigger_ . Any new constraints added after the pg_restore will simply increment the field in the Trigger. Our database is dependent on some of these triggers happening before others. This article explains how constraints/triggers are run. After an upgrade, our constraints were not placed in the same order as created. Causing some errors which have now been addressed by this PR.
Visual:
Pre Upgrade: Constraint Triggers are created in the order the constraints were made

resource_constraint => RI_ConstraintTrigger_1
annotation_constraint => RI_ConstraintTrigger_2

Post pg_dump: Constraints are put in alphabetical and then turned into Triggers

annotation_constraint => RI_ConstraintTrigger_1
resource_constraint => RI_ConstraintTrigger_2

Describe the solution you would like

Here is a list of options that I have considered.

1. Rethink the upgrade process to first do a data dump and then run all of the migrations. To ensure the triggers are placed in the correct order.
2. Simplify the triggers/constraints and ensure that the order does not matter.
3. Move all/majority of the logic into Rails, however, this will likely cause a performance hit.

[izgeri]

@h-artzi does the PR #1949 (which is still a draft) address one of the options you describe (1-3 in the list above)?