External volume and transport features for external plugins

[MikaelSmith]

Add features that external plugins can request Wash provide them from its core capabilities. Implement volume.FS and transport.ExecSSH as features.

[MikaelSmith]

Demonstrated with https://github.com/puppetlabs/boltwash/pull/1 using https://github.com/puppetlabs/wash-ruby/pull/27. Still need to write lots of testing in various places, but this should be useful to get feedback on how you set it up.

[ekinanp]

I think exporting volume.FS and transport makes sense, I'm just not sure if a separate features key is the best way to do it. Here's why I say that:

• features needs to be specified in the entry schema JSON. However, features doesn't contribute to understanding an entry's high-level nature, which is what the entry schema's for. For example, why would a Wash user care about what core Wash features an entry's using? But I also get why you're including it (so that stree <ancestor> shows volume::fs). That reason just feels hacky, and hacky means that it may not be the right way to think about this.

• transport as-it-currently-is just seems to be a plugin author's way of saying "Hey, I'd like to implement my exec using your transport package". It seems like a natural way of extending the method tuple concept to [<method>, <method_specific_info>] where for list it's a prefetched result, for read it's a prefetched result or signature, and for exec, it's an implementation, in this case using stuff in the transport package. So I don't see why we can't stick the transport JSON there.

• volume.fs is "I want to re-use this core-plugin entry". Could we achieve that via something like:

  • Check if list's return contains a core plugin entry JSON. A core plugin entry JSON is an entry JSON that needs (all other keys are ignored):
    • type_id (this is what tells Wash that we're re-using a core-plugin entry). For volume.fs, this could be __volume::fs__ (or w/e type ID that's likely to minimize conflict).
    • name -- For the entry's name
    • state -- Representing the entry-specific config (aka constructor arguments). This is where maxdepth and all that could go.

  For entry schema, we can just check if they provide the core plugin entry type ID in the children key. That does make it harder to override specific schema keys (e.g. if you want to change the description or if you want to change the name [makes singleton entries easier to document if you change fs entry's name for example]), but there's probably a clean way to support that too (have some ideas on that).

[MikaelSmith]

Those make sense to me. I'll work on the details a bit today.

[ekinanp]

Cool, pending tests the changes here look good.

[MikaelSmith]

Added tests, I think just docs remaining.

[MikaelSmith]

Added docs. I can make that a separate PR if needed.

[MikaelSmith]

I'm going to split the docs change into a separate PR so we can merge it around release time.