Componentise Zlux/Zss/zlux-app-server into cupids format

[stevenhorsman]

As a Zowe user,
I want to be able to start the zss and zowe desktop framework and apps with the configuration passed in at runtime and have a separate user_directory/workspace for my instance data
so that I can make changes to my zowe config without having to reinstall and lose my config.

Details/notes

• We'll follow the pattern set out in Launch Zowe with PARMLIB controlled configuration data running in a workspace directory #433 for launching a component and apply it to Zlux app service

• During configure we'll need to inject new properties into run-zowe.sh
  ZOWE_ZLUX_SERVER_HTTPS_PORT - rename this?
  ZOWE_ZSS_SERVER_PORT - rename this?
  ZOWE_ZSS_XMEM_SERVER_NAME - can we look like up/read from the xmem server rather than risk a customer listing twice differently?

• Create a new start.sh script that is created in <zowe_root_dir>/components//bin which runs $DIR/../../zlux-app-server/bin && _BPX_JOBNAME=$ZOWE_DESKTOP ./nodeCluster.sh --allowInvalidTLSProxy=true &?

• In <zowe_root_dir>/components//bin/configure.sh create a new configure.sh script that does all the configure set-up - sed injecting the properties into from shell variables (and others?) based on zowe-configure-zlux-certificates.sh (if required each time), zowe-configure-zlux-ports.sh. Check zowe-config.sh for anything else missing. It also need to inject the correct variables to put zlux behind the APIML gateway - if the gateway is in the launch config (maybe a separate task to document/track component dependencies?)

• Add the new component id to the LAUNCH_COMPONENTS list and remove the old code

• We'll create a follow up story about doing component validation for zlux app server similar to Component variable validation for Files API service #445 after it is refactored to share logic

Questions?

• Does zowe-configure-zlux-certificates.sh need to be done every time, or just once?
• What is the component id for zlux?
• Sean says that some components have read-only defaults, should we keep these in runtime, or copy a default to the user-dir

Acceptance Criteria

Given an run-zowe.sh forked script with defining all the properties
When I run start ZOWE to drive the script
Then ZOWE should start successfully
And when I look at the zowe job address spaces through display active, I can see the zss and desktop services active
And The desktop should be available on port <ZOWE_ZLUX_SERVER_HTTPS_PORT> and zss work on <ZOWE_ZSS_SERVER_PORT>

Given an run-zowe.sh forked script with defining only the properties for the Zlux framework components
When I run start ZOWE to drive the script
Then ZOWE should start successfully
And when I look at the zowe job address spaces through display active, I can see only the zss and desktop services active
And The desktop should be available on port <ZOWE_ZLUX_SERVER_HTTPS_PORT> and zss work on <ZOWE_ZSS_SERVER_PORT>
And None of the apiml components are running.

[Joe-Winchester]

Link to zowe/zlux-app-server#82. We should try to get a componentized lifecycle for ZLUX based on this script.

[nannanli]

Doc impact is tracked in zowe/docs-site#849.

[1000TurquoisePogs]

See PRs for comments.
By the way, I had taken this opportunity to do some changes that were accumulating in the backlog, such as:

What is the component id for zlux?

It's not ZLUX anymore. I tried to remove ZLUX from as many user-facing areas as were reasonable to do without breaking. I'm calling it "app-server"; easier to understand & aligns with the documentation's use of "Zowe Application Server/ Zowe Application Framework"
Similarly, the log file is no longer nodeServer.log. It is appServer.log