Update to V3 API

[lancegliser]

Starting work on #71. Just a draft for visibility as I start hacking at it.

• [X] Update documentation
• [X] Update tests
• [X] Update internals
• [ ] Merge #77 to reduce needless shift
• [X] Manual index.d.ts updates for options.
• [ ] Reap concerns decisions

Changes (I'd suggest squash merging to these 😅)

• v3.0.0
• @aws-sdk/client-dynamodb@^3.218.0
• Refactored client uses to v3 .send(new Command()) promises.
• Refactored DynamoDBStore.prototype.touch to return (err, {expires}) to the callback.
• Moved the table describe and creation logic into an initialize function and ensured all methods call it first to expose errors.
• Updated the client in test to create from env variables directly
• Refactored tests to use more randomized values for value, constants for sessionIds, and reduce duplication.
• Refactored tests to async with Promises so errors in callbacks could be exposed to test results.
• Added a note to the README about the costs associated with scan implementation.
• Added .idea to .gitignore to filter out WebStorm files.

[lancegliser]

@ca98am79 I'll try to keep to JS only, but the Types need some work too. Would you be adverse in the future to moving to tsc?

[ca98am79]

@lancegliser that is fine with me, thank you

[lancegliser]

@ca98am79 The README currently has this warning:

  - `reapInterval` Legacy session expiration cleanup in milliseconds.  Should instead enable [DynamoDB TTL](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) and select the `expires` field.  **BREAKING CHANGE** from v1.0.11 to v2.0.0 for reaping sessions with changes to the format of the expires field timestamp.

I've for now updated to:

- `reapInterval` Legacy session expiration cleanup in milliseconds.
  ☣️ Legacy reap behaviors use DynamoDB [scan](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/clients/client-dynamodb/classes/scancommand.html)
  functionality that can incur significant costs. Should instead enable [DynamoDB TTL](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html)
  and select the `expires` field.

Since we're already making a breaking change, would it be better to remove that and help users avoid shooting themselves in the foot with potential costs? I should be able to use new UpdateTimeToLiveCommand() to apply a sensible default or take it as an option? Related to #72

[lancegliser]

@ca98am79 Alright my friend. I've got this to the point it works when manually npm packed into my project. I'm ready to have you review it.

A few things that might come as surprises I'll explain:

• The wall of white space changes. It might be worth doing #77 first to reduce that.
• "DynamoDBStore.Initializing.*" This was a refactor I took on to deal with timing issues #46 happened to exist before I noticed.. When I first started creating a table, there was no feedback that it failed and potential race conditions as it created. I ripped the logic for table creation out of the constructor and instead call it before making any attempt to reach storage. Should be seamless to users, but a little headache for us.
• "Touching.does not crash on invalid session object" I made an internal refactor here. Felt like the test knew too much about internal structure of Dynamo, so now it's just (err, { expiration }) as callback. That's not exactly what's in express's API. They claim it returns nothing at all. I think that's fine?
• "Getting.does not crash on invalid session object" This got an overhaul due to the initialization changes. The previous mock of getItem was never called anymore. Depending on sequence, send might have been called to: describe table, create table, or get item. I probably could code around that, but it felt like too much knowledge of internals again. Decided I'd just extract the part being tested for more direct access.
• Arrow functions, everywhere!
• Tests are now async () => new Promise all over. This was because the errors in the code were not being show in the tests. The callback style if err throw err weren't part of strict operational control flow. It's been replaced with if err return reject(err) all over to expose those.

[lancegliser]

@ca98am79 We're online using this for a couple weeks now via npm pack install. Can I help in any way to get this merged and published?

[lancegliser]

@ca98am79 Noticed an issue today trying to upgrade from 16.x to 18.x on an AWS Lambda today. I traced it back to the this branch and the package I'd built from it. Wanted to use ScalarAttributeType.*, and it worked on 16.x. I assume 16.x just took the property as the value so ".N" came out correct. 18.x throws an error. I pushed and updated to fix it. Would love to get this published so we can properly version!

[StefanTobler]

Agreed, can we have this reviewed and merged. It is tough to have multiple mocked AWS clients across my different application with AWS sdk different versions.

[ca98am79]

thank you, sorry for the delay