Nylas auth refactor

[thomasst]

• Refactored and simplified auth handlers (inbox/auth/*)
  • Supported providers are "custom", "gmail", "outlook", no more complex module registering logic.
  • Only one token per account (we're assuming the user doesn't have different tokens for email, calendar, contacts)
  • Get rid of GmailAuthCredentials table. We only support one app token.
  • By default store the client ID on the account table to still allow migrating accounts from one client ID to another (This would require some minor work to feed multiple client secrets via config).
  • Kept the verification methods due to many tests using them, but we aren't using them so far.
• API (inbox/api/srv.py) and auth handler now uses attr objects instead of a dict. Supports both token and AuthAlligator auth info.
• Single entry point to obtain an access token via existing TokenManager which can use a refresh token or AuthAlligator (not implemented yet).
  • Email uses get_authenticated_imap_connection for convenience.
  • Events uses existing requests client with token from the token manager.
  • Contacts uses existing Google library but doesn't touch the refresh token since it uses gdata.gauth.AuthSubToken with the token from the token manager.

To do:

• DB Migration (may be in a subsequent PR so it can be deployed later)
• Fix tests
• More testing. Test marking accounts as invalid if token is invalid vs getting a new token.
• Actual AuthAlligator integration (may be in a subsequent PR)

Future to-dos:

• Upgrade SQLAlchemy and use the Enum type properly.
• Automatically expunge objects from sessions so we can shorten SQLAlchemy sessions.

[AlecRosenbaum]

I don't see anything here really objectionable, but the size of this diff makes me nervous.

Beyond automated tests, are we going to do any more testing internally before merging this?

[thomasst]

@AlecRosenbaum Take another look please. The tests should now pass and I did some more local testing. I will still do further testing this week.

[AlecRosenbaum]

There's a lot of stuff going on here so hopefully I didn't miss anything too major.

If possible we should try to add rollbar support before we test this so error response is more proactive than reactive.

[AlecRosenbaum]

We don't need any of the profile information? And they're not reusing the G+ scope for other profile information?

[thomasst]

The profile info was filled in the Gmail account table but is not needed for the sync, so I took it out.

[AlecRosenbaum]

I also definitely think we should merge this separate from actual AuthAlligator integration, primarily to get a baseline that this works and to make it easier to review the more authalligator-specific changes (beyond SecretType + company).