Create a Dedicated Doc Publisher Module

[LeighFinegold]

Issue: Create a Dedicated Doc Publisher Module

Reference: Related to #790

Description

As a pre-requisite to CALM bundling, a Doc Publisher module should be introduced under shared. This module will be responsible for publishing validated CALM documents.

Implementation Plan
Phase 1: Store the documents in memory in a way that SchemaDirectory can resolve them Phase 2: Extend to include CALM Hub publishing and user-defined configurations, with SchemaDirectory also being enhanced to work with CalmHub

The following Issue is Scoped to tackle Phase 1 and allow non maintainers to prime the CLI/CLI server functions with documents

[willosborne]

Things have advanced a bit since this issue was raised. Where we are now: The SchemaDirectory has two implementations for resolving references. One loads from the filesystem by recursively storing all documents in a directory tree into memory. The other looks for any documents not in memory in CalmHub and caches and returns it.

Currently only the validate and generate commands use the SchemaDirectory to load the documents they require. I will be working tomorrow on making validate properly inject the SchemaDirectory so that it can also support calmhub (right now it always uses the filesystem version.) See #1282 .

Now we need to unify the other commands behind this interface. We also need to identify any other dependencies on the file system/ things only available in node within the shared module. See #1283 .

Plan:

1. Refactor validate to inject SchemaDirectory and support CalmHub loading

2. Write an implementation of DocumentLoader that uses the index.json file currently directly implemented by docify and template to load documents. This approach is good in the short term because it doesn't care about what you're loading - just where it is on the filesystem, since you specify your own IDs.

3. Refactor docify and template to use the same abstractions for loading documents, and default to using the index.json implementation so that functionality should be the same. Alternatively they can also use the FileSystemDocLoader to load all the files from a local folder, or the CalmHubDocLoader to resolve things from CalmHub. Note: this can only resolve schemas right now, because the API for controls and interfaces doesn't exist yet. Hence the desire to stick with the index.json approach first which can load anything you want as long as it has an $id.

4. Identify any other IO parts of the shared module and create abstractions (or 'ports' in hexagonal arch lingo) for them, and refactor so they use them. See #1283. Note that CalmHub integration works fine from the browser, so we can leave that in shared.

5. Write 'adapters' (in hexagonal arch lingo) for these IO parts in CLI module and remove the dependencies from shared, making browser support for shared module fine.

Additional features to support this:

Write a command to easily register a local file in an index.json. You give it a filename and it just stores it in the index for easy use. This is equivalent to the FileSystemDocLoader but doesn't constrain you to just loading all files from a folder on your machine