When creating models, EvolveAppTask was generating and storing the SQL
for an entire model creation, which included not just the CREATE TABLE
but any deferred constraints. Each batch of SQL statements would later
be executed in order. If any of these SQL statements contained
constraints that referenced a table introduced by a subsequent task, the
SQL would fail to execute, because that table wouldn't have existed yet.
What's supposed to happen is that the deferred statements are executed
after the tables are created. Hence the "deferred" part. The way the
logic worked, this wasn't possible. SchemaEditor knows how to do this
correctly, as does our legacy logic for Django 1.6, but they require
having the full list of new models (not just a subset) passed to them.
This change redoes this logic to gather all models up-front and to
generate the SQL in one go, ensuring that the ordering of statements is
correct. The only real behavioral change introduced from this is that we
have to emit all creating_models signals up-front, and then emit all
created_models after all models are created, rather than emitting
these in pairs. This means that callers can't expect to receive them in
that order.
It also means that the evolve command will be listing all
"Creating new database models for ..." up-front, rather than when each
model will be created. It's an annoyance, but hopefully a mostly
harmless one, and is necessary without a much larger reworking of how
this SQL is generated.
