Improve client AT-TLS handling

Is your feature request related to a problem? Please describe.
In AT-TLS scenarios:

• If using ICSF hardware-stored key:
  All routes starting from GW will need AT-TLS outbound enabled (controlled via client.attls setting)

Currently, these requests depend on whether https is enabled in the service data in eureka.

In container scenarios, we want to avoid sending plain text to a service even if AT-TLS inbound is enabled on it (i.e. ZSS)

Another thing the API ML services don't handle properly currently is that we only verify the global setting, while the setting can also be set on a component level in zowe.yaml.

Describe the solution you'd like

• Gateway could rely on the client.attls setting to determine if the internal communication should go through HTTP (client.attls enabled) or https (client.attls disabled)
• In container scenarios this parameter should be disabled by default.
• There could be logic to determine when to override the expected protocol in the service (registration data vs client.attls enabled or disabled)

Describe alternatives you've considered
Services simply switching the secure or normal port in the eureka registration may be insecure.

Start at the Gateway handling of the client.attls setting and the component-level settings in zowe.yaml. Trace how Eureka service registration currently determines HTTP versus HTTPS, including container scenarios and API ML services. Done means internal requests consistently use the intended protocol without relying solely on service registration data.