GPII-1897: Isolate buildup and teardown to allow for persistence between runs.

[the-t-in-rtf]

See GPII-1897 for details.

[the-t-in-rtf]

Even with my best efforts, I cannot seem to get the in-memory memdown-backed grade to consistently clear itself out. I get constant errors like:

{ [conflict: Document update conflict]
  status: 409,
  name: 'conflict',
  message: 'Document update conflict',
  error: true }

I only get the errors when loading test data, likely these are records with hard-coded _id values, which cannot be overridden (records without would silently result in duplicates). I have a few checks to confirm that no duplicates are created, but obviously not enough, as I can't catch the problem behavior even across a wider range of test runs.

We should look at this as part of this PR. It may be that we can mitigate this by removing in-memory storage as an option for express-pouchdb, and only allowing in-memory databases on the browser side. Now that the filesystem-backed grade has been better fleshed out, I'm happy only using that in my own work.

[the-t-in-rtf]

The new gpii.pouch grade is now integrated into gpii.pouch.express. This should be ready for further review, and for Cindy and Simon to examine.

[amb26]

This must never be done - the fact that it still works is just the blindest accident and will be cleaned up in the next framework update. Always use initDependent (if you must have a programmatic API) or preferably the Nexus methods such as fluid.construct

[the-t-in-rtf]

The programmatic API was used to support the previous databases option rather than forcing everyone to define subcomponents for each database. I will try the Nexus methods here and we can review later.

[the-t-in-rtf]

Done, I migrated to using fluid.construct.

[the-t-in-rtf]

Looking at this in light of other comments, dbOptions can easily become the basis of the options set for the "array of dynamic components" we've been discussing.

[the-t-in-rtf]

This needs to be merged after gpii-express, so that we can move to a published version.

[amb26]

Type of {Number} doesn't seem right here

[the-t-in-rtf]

Fixed.

[the-t-in-rtf]

@cindyli, I have completed the refactor we discussed in our last meeting. We now use the previous "destroy" method to cleanup database instances. Please confirm if this works for you.

[amb26]

Note that the strategy for sequencing test runs in package.json fails on Windows:
"test": "npm run test:browser; npm run test:node",

[the-t-in-rtf]

Thanks, @amb26. Based on our frequent use of && across platforms, I foolishly assumed a semicolon would work as well. I have updated the definition to use && instead.

[the-t-in-rtf]

To summarize, after much effort the project is in a usable state at the moment. As mentioned above, I have created issues for the remaining work, which now includes tracking down the underlying source of the 409 errors:

1. GPII-2162 (document conflicts)
2. GPII-1995 (migrating away from event wrappers)
3. GPII-2163 (using dynamic components instead of the current databases option in gpii.pouch.express)

@cindyli and @amb26, I hope that a) I have summarized the work remaining correctly and b) we can agree to merge what we have.

[amb26]

With respect to the discussion below about inclusion of "path", this require is ineffective. All it does is load path into your global object, not into Infusion's.
The safe way of ensuring that "path" is available for global resolution is to write
fluid.require("path", require, "path");
http://docs.fluidproject.org/infusion/development/NodeAPI.html#fluid-require-modulename-foreignrequire-namespace-

[the-t-in-rtf]

Thanks, and fixed. Given that I had to tiptoe around the ESLint "unused variable" warning, it should be easy enough to remember when this is relevant in the future.