Updating documentation based on Layer meeting feedback

Summary: Only modifies docs

Test Plan: Read over docs and provide feedback

Reviewers: spang

Differential Revision: https://review.inboxapp.com/D242

Conflicts:
	inbox/docs/api/05_tags.mdown
Initial cred checker.

Summary:
[cred-checker] Initial cred-checker script + refactoring.

[cred-checker] live account table.

[cred-checker] Add some logging support.

[cred-checker] test database.

Refs T139

Test Plan: review code

Reviewers: emfree

Reviewed By: emfree

Maniphest Tasks: T139

Differential Revision: https://review.inboxapp.com/D246
Fix migration 053 when email addresses or non-null but not parseable.
Order API responses most-recent-first when order_by=date.

Not least-recent-first. Dammit.
Periodically refresh IMAP flags for those servers that don't support CONDSTORE

Summary:
Christine,

I integrated the changes we talked about yesterday. Here's what I think you should take a look at first:

- I've decided to spawn a new greenlet to update IMAP flags during a full sync. I thought it would be cleaner this way (imap.py:561). To do this I defined a new function "imap_check_flags" which was largely copy-pasted from another one. Tell me if you think there's stuff which should be abstracted away.

- IMAP updates are limited to the highest "refresh_flags_max" UIDs (2000 by default, but this is a constructor parameter). I must say I haven't found a better variable name so I'm open to suggestions.

Test Plan: Ran a smoke test. Triggered a full sync and paused the program with a debugger. Checked that the fields where updated in the db.

Reviewers: spang

Reviewed By: spang

Differential Revision: https://review.inboxapp.com/D241
[migrations/051] Fix store_secrets_in_local_vault migration downgrade.

Summary: There was an error on the downgrade path of this migration.

Test Plan: View code.

Reviewers: emfree

Reviewed By: emfree

Differential Revision: https://review.inboxapp.com/D253
[SCHEMA] Remove duplicate Gmail message data and tighten constraints.

Some bugs caused Message objects to occasionally be duplicated for Gmail
accounts. I'm not 100% sure we've eradicated them all, but tightening
the constraints on the table will make it easier to make sure.

Note that MySQL does not apply unique constraints against rows on which
some of the columns to constraint are NULL, so this does not affect
non-Gmail accounts (which do not have a g_msgid).
Fix up a comment and log error.
Fix database session bug which results in creation of multiple Thread objects on Gmail.
Fix argument ordering in migraton 056.
Fix argument ordering in migraton 056.
Fixes T138 and then some:
Include account_id in exceptions email,
Include errors in Monocle.

Summary:
To include account_id in the exceptions email, we simply use an extra account_id param;
I did some quick, prelim digging into directly using the account_id that the logger is initialized with
(through the event_dict passed to the structlog processors) but that seemed unnecessarily complicated.

The changes to include errors in Monocle should be more obvious;
we currently store the error in the database table itself because that's where Monocle pulls its data from but eventually,
we should move to a different approach.
Note that this rev includes a migration to change how we store sync_status info in models.account (switched to using a single JSON column)

Test Plan:
Visual app inspection.
Sync runs as before.

Reviewers: emfree

Reviewed By: emfree

Subscribers: spang

Maniphest Tasks: T138

Differential Revision: https://review.inboxapp.com/D249
[SCHEMA] Truncate message subjects to 255 characters.

Fixes DataErrors caused by subjects that overflow the size of MySQL's TEXT.
Fix alembic revision branch.
Make sure to commit final objects in migration 057.
[SCHEMA] Explicitly schedule syncback actions, instead of using the transaction log.

Summary:
Fixes T167, by removing the offending code altogether.

Instead of inferring syncback actions to execute from the generic transaction
log, explicitly store them in the new ActionLog table. This provides the
following benefits:

 * It's easier to ensure that syncback actions are executed when they should
   be. For example, if a user marks a single message as read via the API, we
   want to sync that back. But if we change a message's read status in
   mailsync, we don't want to schedule a syncback action. It's currently
   impossible to distinguish those two scenarios just by interpreting the
   transaction log. Similarly, we had to clunkily distinguish between tags that
   were set via the API and tags that were set from mailsync.

 * The SyncbackService doesn't need to process the *entire* transaction log.

Test Plan: Unit tests, and manually san-checking syncback actions.

Reviewers: kav-ya

Reviewed By: kav-ya

Subscribers: spang

Maniphest Tasks: T167

Differential Revision: https://review.inboxapp.com/D248
[SCHEMA] Migration to cascade Folder deletes to EASUid
[SCHEMA] Migration to remove EASFolderSyncStatus + Folder rows we never sync.
[SCHEMA] Fixes T171: Data too long for column message_id_header

We up the max column length to 998 in accordance with http://tools.ietf.org/html/rfc4130 (section 5.3.3)
(We can't truncate this header because it is used to populate the In-Reply-To header on
messages we send).
Add a try/except to  migration 061.