Fix Eureka Registration when ATTLS (v3)

[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.

[pablocarle]

Hi, I wonder how does the desktop handle the registration itself under this context?
I'm asking more precisely about the metadata, it would be assumed that if outbound rule is enabled for Zlux -> Discovery, it may be also enabled for Gw -> Zlux, so the question is if zlux will be reached using HTTP in routing.

[1000TurquoisePogs]

@pablocarle in communication there are places that must be aware of ATTLS and other places that should not be aware.

The app-server must be aware of ATTLS when sending traffic out, so that it does not create double-TLS. So, it must send as HTTP when ATTLS is on.

But because the receiver (discovery) and anything that contacts the app-server (gateway) will also be using ATTLS, they will see any HTTP traffic as HTTPS.

So, in this code, the metadata must claim that the connection is 100% HTTPS, 0% HTTP.
Because by all external observers that is what it is. It's just that ATTLS is the thing accomplishing that.

When writing that I checked and noticed I almost made a regression about that. So, fixed it 5f84184