sqlite downgrades

[sssoleileraaa]

Descriptoin

Sqlite doesn't support alter table drop column so creating an sqlalchemy downgrade requires a workaround. It's pretty straight-forward: use batch_alter_table, e.g.

    with op.batch_alter_table('users', schema=None) as batch_op:
        batch_op.drop_column('lastname')
        batch_op.drop_column('firstname')

However, maybe it makes more sense to restore a backup, which can be more reliable and/or faster than to do a downgrade, depending on database size. The client's database might not ever be so large that performance is an issue, but we should add notes to our migration policy/ documenation in the client's README.md after discussing this further as a group.

[redshiftzero]

These are the reasons I can think of where we'd want to roll back either via alembic downgrades or backup/restore:

1. Ease of development, e.g. I use the upgrades/downgrades in dev so that I can keep one db/data files directory with a bunch of test data and quickly hop between different branches with different migration histories
2. Production: Migration upgrade failure - we have this in core but we should consider doing here also (slightly less pressing here since most of the data except the eventual read/unread status can be replicated from the server). In SecureDrop core after a package update before we start the application again we backup the database, attempt the migration, if successful remove the backup.
3. Production: Roll back to a previous packaged version of the application after using client for some period of time. This is a separate category because restoring the backup from before the upgrade will mean data loss. It's worth double checking but I think that since the existing packaging logic is such that alembic upgrade head is ran in prior to running the client each time, if you roll back from securedrop-client-N+1 down to to securedrop-client-N, the svs database will be intact and will continue to work with the logic in securedrop-client-N because the downgrades will run, which is very nice imho (especially for testing nightly debs that are likely going to contain bad bugs at some point).

[eloquence]

No further action required on this issue; see #453 for context where this came up - the batch_alter_table operation used for this alembic migration seems to work fine for downgrades.