chore: enforce USE_TZ setting expectations in migrations

[jennifer-richards]

This pull request resets USE_TZ=False in settings.py. This is needed so that migrations before the timestamp conversion can be run on dev systems.

A check that USE_TZ is still False is added to the timestamp conversion migration. That setting must not be changed until after we migrate the DB.

An additional dummy migration is added after timestamp conversion. This will fail, interrupting migrations so the admin can update the USE_TZ setting to True at the correct point in the sequence.

[rjsparks]

This is a developer-convenience bit of tooling? Or are you anticipating that the production release will require a step where migrations fail and then have to be rerun after changing USE_TZ manually?

[jennifer-richards]

It was motivated for developer convenience. For production, we will need to arrange for the USE_TZ flag to be switched at the same point. We could do that as is done here, or by ensuring we handle this migration in isolation.

The guards I've put in here are ok to warn that you've probably already corrupted your timestamp data, but outside of dev that's of limited value. There's really no robust way to manage a change in the USE_TZ setting as a typical migration. It may be a good time to squash migrations to get rid of historical code that requires USE_TZ be False.