Deduplication of network definitions

[eak13]

Problem description (if applicable)
As an operator, I need the ability to specify common networking information at various levels of specificity while also being able to override & specify specific values down to the site & sub-type level.

The different levels of specificity could be:

• global
• type (common across clusters of a similar type, e.g. DNS servers)
• clusters (e.g. gateway IP addresses)
• sub-set of hosts within a cluster (control plane vs. worker node)
• single host (e.g. IP address)

Proposed change
This issue requires some level of design/investigation to determine the following

1. Look at the node level networkData settings which have been applied in the POC lab and make sure it’s all injectable via the common-networking.yaml catalogue at the type level.
2. Determine what references exist to IP addresses defined in hosts.yaml and common-networking.yaml that aren’t deduplicated via the hostgenerator. From this identification, we will determine the location from where they should be placed & retrieved (e.g. host.yaml or common-networking, etc.).
   Samples can be found here:
   https://review.opendev.org/#/c/735033/25/manifests/site/test-site/shared/catalogues/hosts.yaml
   https://review.opendev.org/#/c/735033/25/manifests/type/gating/shared/catalogues/common-networking.yaml
3. Determine if there’s any other networking information that needs to be deduplicated, and what the right level to capture that information. For example, networking config in the calico function, like pod network ip range – that’s probably also needed by capbk, and we don’t want to have to specify it in two places. https://github.com/airshipit/airshipctl/issues/new/choose

[mattmceuen]

There are a number of 10.x.x.x IP addresses that are are coded in the airshipctl function definitions. Those will need to be turned into placeholders or defaults, with replacement rules defined at the function level and exercised at the site level.

The ironic provisioning_ip, dhcp_range, and provisioning_interface are currently patched at the site level in the ephemeral phase. We need to determine if that's good enough, or if we want to pull them out of e.g. common-networking catalogue (which is defined at type level, but can be overridden at site level) and/or the host catalogue.

[mattmceuen]

https://review.opendev.org/#/c/749611/

[mattmceuen]

This is complete with the Treasuremap change that has merged here: https://review.opendev.org/#/c/753684/