fix: Semantic of onboarded Gateways in the multitenancy deployment

[pj892031]

Description

This PR solves registration on multiple Gateways to the central Discovery service. To explain the issue let take a look on the multitenancy deployment. There is one central APIML instance and multiple domain one:

Domain APIML 1:

• Discovery service
• Gateway
  • it is onboarded on local Discovery Service and has an additional registration (to the central Discovery service)
• ZAAS
• API Catalog
• other services

Domain APIML 2+:

• the same structure and the similar configuration as Domain APIML 1

Central APIML:

• Discovery service
• Gateway
• API Catalog
• other services

Note: In version 2 is instead of Gateway used cloud-gateway on level of central APIML instance.

The main issue is that on central level they are registred all gateways (all domain instance and the cetral one as well). There is missing semantic because all those instances have the same serviceId (gateway), In the v2 it was a little bit better, because they were separated from the central one. Anyway merging of Gateways from different domain does not make any sense. They have different purposes, but they looks like HA instances.

There is no way, how to automatically select the Gateway in the central APIML instance. Also API Catalog in the central Gateway merge all Gateways together (it shows one of them - randomly selected instance).

The solution on how to add a (basic) sematic is to use metadata value (apiml.registrationType=<primary|additional>). It allows to find the instance from the central APIML. For other is allows to use apimlId as serviceId (the same mechanism used in the Gateway).

The PR is mainly about adding the attribute apiml.registrationType, but it also contains these fixes:

• API Catalog split Gateway into multiple records (each for any APIML instance)
• Fix overriding routing paths for additional registration
• Fix configuration for multi-tenancy integration tests

Linked to #3873
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

[sonarcloud]

Quality Gate failed

Failed conditions
74.4% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud