Pull fields out of binary BLOBs

[remerle]

In order to allow for metric gathering, as well as more sophisticated searching within the application, we need to move away from using BLOBs to store data. BLOBs are opaque and unqueryable.

• Any place where a BLOB is not strictly necessary (were we'd need multiple tables to house the data), pull the data from the BLOB up into fields
• Any place where a BLOB still makes sense, pull up any fields that may be important for querying (all fields where pulling them up into the table wouldn't necessitate extra tables to house the relationships)

Impact

• This will be a breaking change which will require migration
• It will be important to drop DynamoDB support (Remove DynamoDB module #971) since DynamoDB cannot easily support the types of queries that we'd want to perform against the new columns. It's possible, but it'd be ugly and the wrong tool for the job.

Some discussion on migration is in #960

[pauljamescleary]

A few things for consideration:

1. Currently blobs are passed via commands (like RecordSetChange) in the message queue
2. When loading very large zones for the purposes of doing a zone sync, we load all records at one time in order to perform a massive diff operation. This is fast for few records, but zones that have 100,000 records this can take a long time to complete. The protobufs are excellent in this regard due to their very small size for this operation. If we remove blobs, we need to optimize the zone sync process.

[remerle]

This issue just looks to solve the opaqueness problem, so let's be sure to keep blobs where necessary for zone sync and queueing.

However, let's consider a hash-based approach to zone sync once we open up the hood. Follow up with a secondary issue to tackle that when/where it makes sense.