Refactor to make better use of native aws-sdk

[rclark]

I've been thinking critically over the weekend about dyno. I'm feeling like several of the helpful aspects that dyno has provided have become convoluted or are now supported by the AWS SDK for JS:

• dyno has lagged and has no clear plan for the support of condition & update expressions, leaving it unable to manipulate parts of List and Map attributes atomically
• dyno recently developed mixed support for "dyno-style" objects and for "wire formatted" objects. This continues to be awkward to manage and maintain
• dyno's lingo for specifying conditions and pagination aren't bad, but they are certainly not nearly as well documented as the aws-sdk
• aws-sdk now has an embedded support for "dyno-style" objects: https://aws.amazon.com/about-aws/whats-new/2015/09/amazon-dynamodb-develop-locally-scale-globally/

This has left me trying to list out what dyno's biggest contributions are at this point. I wonder if dyno needs to undergo some significant refactoring to focus on these aspects:

• Able to turn the caller's batch needs into multiple HTTP requests that fall within the constraints of DynamoDB's batch requests limits
• Readable streams of query and scan results that emit per-item and cross pagination boundaries
• Present, but poor, support for aggregating consumed capacity metrics across multiple requests
• Some pretty useful CLI tools
• Dyno.multi which basically just routes read and write requests to two different tables

I believe we might be able to make dyno more maintainable by building the dyno client as an extension of an aws-sdk client, without overriding that client's methods like we do now. We could inherit getItem, putItem, etc. from the aws-sdk, and provide our own methods focused on the things dyno can still contribute.

Definitely looking for thoughts and input on this @mick @willwhite. Did I miss anything that you consider important dyno functionality that's not offered by the aws-sdk? Talk me back from the ledge please.

[rclark]

I sketched out what an index.js might look like in my mind's eye, including notes on what/why certain things. https://gist.github.com/rclark/5fd3fe13205230fced66

[mick]

I think this all makes sense, and its good to rely more on aws-sdk now that it has caught up. This is going to include a lot of small breaking changes, but probably worth it.

[rclark]

a lot of small breaking changes

Wonder if you have something else in mind... but I'm seeing fairly solid breaking changes. Would you want to try and map the dyno-style expression of conditions and stuff into aws-sdk parameters still? While I don't mind the format niceties, I also really like the aws-sdk's docs.

[rclark]

Done in #106.