Implement a uid/thread-polling helper for IMAP/Gmail initial sync.

Summary:
In the case that a user has e.g. a very large inbox, our current design has the
shortcoming that, during the initial sync, it won't continue to download new
messages. This is untenable for the user experience, so we're solving it by
having a parallel greenlet during this time that keeps checking for new
UIDs/threads and adding them to the top of the initial sync uid/thread download
stack.

By doing this, we have to get rid of the "chunked download" feature...  if we
batch download messages in groups, we'll introduce a delay with how fast we
download new UIDs. It's not clear to me that batching actually wins us that
much speed anyway.

I think we're going to need to introduce IDLE support at some point for
the quickest receipt of new mail, but this is better than what we've got
for now.

Test Plan: ./runtests + a bunch of manual testing that has me thinking real hard about how to do better automatic testing.

Reviewers: mg

Reviewed By: mg

CC: kav-ya, emfree

Differential Revision: https://review.inboxapp.com/D51
Add some new MX records for Google mail servers
Lint tables.base and don't drop to pdb on txn errors.
Use a gevent Group instead of a list to keep track of folder monitors.

This is cleaner and more concise and probably more efficient since we're
not running an endless loop that just yields every iteration. More on
groups at http://sdiehl.github.io/gevent-tutorial/#groups-and-pools.
Fix tests in test_api.py.