Merge current migration before release to reduce number of migrations that must occur

[heartsucker]

Additionally, if we implement #47, then we will need to rewrite these anyway to include the new key names.

[redshiftzero]

yep, we should definitely squash migrations prior to beta

[heartsucker]

Note that if #112 is merged, we must implement this before the beta is rolled out.

[heartsucker]

I want to reopen this for a couple reasons.

First, there was an annoying error in the first migration, namely that we defined a constraint on a column in the migration as ck_replies_is_downloaded but this should have been defined as either op.f(ck_replies_is_downloaded or simply is_downloaded. Failing to do so created a constraint named ck_replies_ck_replies_is_downloaded. This is not inline with our naming convention and should be migrated to line up otherwise future migrations will need to remember this.

Additionally in order to support #203, #207, and #170, we need to write some annoying migrations that require dropping tables and either bulk or iteratively inserting columns. These lead to a significant increase in complexity for implementing #55.

The reason discussed with @redshiftzero for adding migrations as new features come in (namely for adding the fingerprint column as part of #190) was to support devs and auditors who are using this via the deb package (#190 (comment)). I really think it's worth while to tell devs / auditors to just blow away their local db in order to make this change to prevent breakage and code complexity this early in the lifetime of this project.

[heartsucker]

For reference, see the change on this branch: https://github.com/freedomofpress/securedrop-client/tree/alembic-tests

[redshiftzero]

Ok we can do that since I'm with you that it is pretty cumbersome to write lots of table-dropping SQL migrations, but we should triple check that we are happy with the database structure for the beta release as it will be set in stone as it were. Auditors will be 100% done in a week-ish which means that the only people that need to blow away their client directory are the small number of developers using this on Qubes (let's just ask people to do this once), which I think is acceptable.

[heartsucker]

Note that this likely depends on #217.

[redshiftzero]

Closing this since we are adding database changes to the now single migration script for beta here: https://github.com/freedomofpress/securedrop-client/blob/master/alembic/versions/2f363b3d680e_init.py

We also have a note in the README generically describing the process of merging migrations before releases here: https://github.com/freedomofpress/securedrop-client#merging-migrations