Split up 'zwe component install' to improve dry-run capabilities

[1000TurquoisePogs]

Currently, "zwe components install" has 2 subcommands, "extract" and "process-hook"
These are overloaded and weird, so if someone was trying to dry-run through them, they should be reorganized to facilitate that.

A lot of the portions of extension installation dont have granular dry-run, so reorganzing the parts will also require that good dry-run functionality is implemented.
Ideally, that means that we can create temp files/datasets, and show their contents, but not commit them over originals. or, if attributes of a file is to be changed (pc bit, tagging), then we print what would have been performed, but not do it.

I propose this new organization

1. extract or symlink. this command currently has no 'dry-run' at all, so that needs to be added. (current command: zwe components install extract, suggested new name: zwe components install extract)

• ensures the zowe.extensionDirectory exists
• checks if the input is a directory or a file archive
  • if directory, creates a temporary symlink in zowe.extensionDirectory
  • if file archive, tries to extract it into a temporary folder in zowe.extensionDirectory
• verifies that the result has a valid manifest against schema, to avoid user error or corruption
• if the manifest of the component requests the component to be auto-tagged upon install, runs the tag-files.sh script to tag files according to their filename extensions
• checks for and verifies if the extension has any plugins, to avoid developer error or corruption
• renames the temporary directory to the name of the component as seen in the manifest, indicating successful extract

2. run extension install script if exists (current command: zwe components install process-hook, new command: zwe components install extension-script)

• if the extension has an install script, runs it
• if dry-run mode, just print the location of this script and its contents for review

3. do zowe appfw integration (current command: zwe components install process-hook, new command: zwe components install registration appfw)

• checks every appfw plugin in the extension for zss dataservices. if any exist, verifies/corrects to ensure they have the PC bit.

4. do zowe zis integration (current command: zwe components install process-hook, new command: zwe components install registration zis loadlib)

• checks the extension for zis plugins. if any exist,
  • copies them to apf auth dataset
  • updates the zis parmlib
  • unless, with new enhancement, the steplib of the STCs gets updated instead

5. do zowe zis parmlib update (current command: zwe components install process-hook, new command: zwe components install registration zis parmlib)

• modifies zis parmlib with entries from zis plugin

zis process is interesting, thus broken up into 2 parts.

6. enable the extension in the yaml. this is just about running zwe components enable from within the zwe components install. can leave unchanged.

components:
  <component-name>:
    enabled: true

[1000TurquoisePogs]

its important that the zwe components install and zwe components upgrade commands still perform the same operations as before, but with this change, they'll be doing it by doing more sub-commands.

so, i dont think this would break any users, but it would provide more granularity in case of dry-run or troubleshooting.

[MarkAckert]

Similar to your comment on install and upgrade, is the intent for v3 that process-hook aliases the broken-up collection of sub-commands to avoid breaking any users?

Should any of these commands be converted to JCL?