[SCHEMA] Search index operations through the transaction log.

Summary:
We currently re-index all the namespaces (i.e. all messages, threads) in the database periodically.
This suffers from a few key shortcomings:
1. Changes due to sync, syncback are not reflected in search until the next re-index is complete (run as an hourly cron job right now).
2. Deletes are not supported.
3. Is obviously slow/inefficient.

So, leverage our transaction logic instead.
The SearchIndexService - run as a separate process - periodically polls the Transaction table (set to 30s),
translates the database changes for the messages, threads of all namespaces to the corresponding
Elasticsearch index operations and performs them.

* Support for index insert, update, delete operations.

* Support for process restarts - the id of the last processed (i.e. indexed) transaction is
persisted to/retrieved from the database.

Note:
The current implementation of the SearchIndexService is namespace agnostic.
An alternate implementation would be to perform the polling/indexing per-namespace and store the
last_processed_txn per-namespace too.
I don't have a compelling argument for the latter, which is more complicated too, and hence went with the former.

The `searchindexcursor` table will only ever have one row (Alembic uses the `alembic_version` table in a similar way too).

Migration included.
Test underway.

Test Plan:
Tested locally, manually.
Will be tested on staging.

Reviewers: emfree

Reviewed By: emfree

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