Revert encryption migration.
Consolidate ALTER statements and remove subquery within DELETE.

MySQL won't allow a DELETE with a subquery on the same table in case of
cycles, so we need to execute the subquery separately. We also combine
ALTER statements on the same table to let the database optimize the
operation.
Consolidate ALTER statements for migration performance.

Summary:
Doing multiple ALTERs separately may result in multiple table copies. This
modification makes this migration run in ~3min on production. (Not sure what
it was before except for "longer".)

Test Plan: comparison of emitted SQL with echo=True

Reviewers: charles

Reviewed By: charles

Differential Revision: https://review.inboxapp.com/D430
[SCHEMA] Revert EAS passwords migration.
Remove migration 091, not needed anymore.
[WIP] Detect flag changes during initial sync.

In this chapter of the IMAP sync saga, we restructure the Gmail and condstore
sync engines to allow us to detect flag changes during initial sync.

For Gmail, we'd previously run __check_new_g_thrids() in a separate greenlet
during initial sync. However, this wouldn't detect flag changes (marking a
thread as read, etc.).

The key observation is that during initial sync, we should really be doing the
same highestmodseq-updating that we do when polling, in order to fully detect
changes.

This commit replaces the `check_new_uids()`, `__check_new_g_thrids()`,
and `__imap_flag_change_poller()`, and `__check_flags()` greenlets by a single
`poll_for_changes()` greenlet, which has one implementation for condstore and
one for non-condstore IMAP sync.

Smaller associated changes:
 * Define classes UIDStack and GMessageStack that wrap gevent.LifoQueue, to
   allow for more concise manipulations of the download stacks.
 * Don't track `update_uid_count` or `delete_uid_count` when calling
   update_uid_counts() -- we don't actually use those numbers for anything.