fix: Fix URLs for onboarding when AT-TLS is enabled

[pj892031]

Description

This PR fixes the configuration of URLs (ie. Swagger) in AT-TLS mode. It is necessary to understand that the API Catalog uses the same URL as the service provides. It means the service should decide if the Swagger URL is http or https based on the existence of a TTLS outbound rule from the Gateway to the service.

This PR modifies the configuration to define ATTLS enabled for client (outbound rules) and server (inbound rules) in parallel to respect zowe.yaml configuration.

There are multiple issues:

type 1:

api-layer/api-catalog-services/src/main/resources/application.yml

Lines 163 to 167 in d1b6972

	apiInfo:
	- apiId: zowe.apiml.apicatalog
	version: 1.0.0
	gatewayUrl: api/v1
	swaggerUrl: https://${apiml.service.hostname}:${apiml.service.port}${apiml.service.contextPath}/v3/api-docs

The configuration of the URL is based on server configuration, which is not true because the protocol should be changed based on an outbound rule. Usually, both sides are configured together, so it is more complicated to find it.

type 2:

There is no way to configure the protocol at all. The AT-TLS profile does not override it:

https://github.com/zowe/api-layer/blob/d1b697258ccd7bf6aa65523984b8a95dcddee16c/gateway-service/src/main/resources/application.yml#L29-34

https://github.com/zowe/api-layer/blob/d1b697258ccd7bf6aa65523984b8a95dcddee16c/gateway-service/src/main/resources/application.yml#L191-206

Linked to # (issue)
Part of the # (epic)

Type of change

Please delete options that are not relevant.

• fix: Bug fix (non-breaking change which fixes an issue)
• feat: New feature (non-breaking change which adds functionality)
• docs: Change in a documentation
• refactor: Refactor the code
• chore: Chore, repository cleanup, updates the dependencies.
• BREAKING CHANGE or !: Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code follows the style guidelines of this project
• PR title conforms to commit message guideline ## Commit Message Structure Guideline
• I have commented my code, particularly in hard-to-understand areas. In JS I did provide JSDoc
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The java tests in the area I was working on leverage @nested annotations
• Any dependent changes have been merged and published in downstream modules

For more details about how should the code look like read the Contributing guideline

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud