Fix Eureka Registration when ATTLS (v2)

[1000TurquoisePogs]

app-server should use "utils.isClientAttls()" to determine if outbound network requests should be https (if not attls) or http (if attls, because then attls adds the tls, becoming https in the end).

It appears that apiml.js does not do these checks when doing eureka registration, so when attls is used, it does double-tls, resulting in the repeated error:

Eureka request failed to endpoint ..., next server retry...

This error can be seen under normal circumstances due to a timing issue, but eventually resolves to a message

" registered with eureka:..."

In the case of attls, due to the double-tls failure, success never occurs and the "eureka request failed to endpoint" continues forever.

In this PR, I use "isClientAttls" in a few places.
In my testing, it is only truly needed in "getServiceUrls()"
However, through reading documentation of https://www.npmjs.com/package/@rocketsoftware/eureka-js-client and checking other areas in this code, I identified 4 places where it would be best to be explicitly either http or https, rather than allowing the eureka-js-client library to do some implicit behavior that may change in the future.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

PR Checklist

Please delete options that are not relevant.

• If the changes in this PR are meant for the next release / mainline, this PR targets the "staging" branch.
• My code follows the style guidelines of this project (see: Contributing guideline)
• Relevant update to CHANGELOG.md
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works, or describe a test method below

Testing

• Toggle "zowe.network.server.tls.attls" and "zowe.network.client.tls.attls" so that they are either both true or both false.
• When both false, there should be no regression. Its the default and currently works.
• When both true, " registered with eureka:..." should be seen in log. It is seen whenever you have a valid network configuration (AT-TLS or not) between app-server and discovery.
• seeing "Eureka request failed to endpoint ..., next server retry..." in the log at first is normal, but if it continues without " registered with eureka:..." then it is a problem.
• env var "NODE_DEBUG: tls,request" can be used to observe what network activity app-server does before these "eureka" messages appear. You should see "http://" urls and no "TLS" messages when AT-TLS is enabled. You should see "https://" and "TLS" messages when AT-TLS is disabled.

[skurnevich]

Hi Sean, great to see that, yes i've come up to the same results, that app server is still trying to use https to contact Eureka in at-tls, was hoping to address that with different pagent rules, wouldn't be correct at-tls i just wanted to find a workaround.
Anyway, i'll be able to test this PR only after holidays, but there a few things that are pop up in my head from previous tests:
The function below (getRequestOptionsArray) uses hardcoded 8 characters to slice for "https://" and so it will cut one char from host name in case of "http://"
Also a minor schema thing, we allow using custom URL for discoveryUrls in zowe.yaml
app-server.node.mediationLayer.server.discoveryUrls
However schema will expect https there and will break if we use http url there.

[1000TurquoisePogs]

discoveryUrls comes from the discovery env var unless from this override of app-server.node.mediationLayer.server.discoveryUrls
in that env var, it's always "https://"
getServiceUrls() is now returning URLs that could be https or http.
But getRequestOptionsArray() isnt transforming the input, it's just extracting host & port. So I think it's okay that it's hardcoded to https:// still.
I also think app-server.node.mediationLayer.server.discoveryUrls should never have "http", it should always be "https".

The code could be improved to guarantee these things?