unified host identity abstraction in CMAPI

Problem:
Currently, there is no consistent source of truth for host identities across the cluster. Hosts may be added either by hostname or by IP address. Inside the system these values can be converted or stored differently depending on the component. This leads to multiple issues:
• A hostname may resolve to multiple addresses, and an address may resolve back to multiple or incorrect hostnames.
• Some hostnames do not resolve at all, or resolve only locally (e.g., Debian adds local aliases that are invisible to other hosts).
• Components may store and compare hostnames in some places and IP addresses in others. As a result, a host may fail to recognize itself as “active” when checking the Active/Desired/Inactive lists, even though it is part of the cluster.
• Failover logic may misinterpret a host as missing, because it compares against a local alias or mismatched representation.

These inconsistencies make the cluster fragile: small changes in environment (DNS, nsswitch configuration, aliases) can cause nodes to fail health checks, skip service startup, or trigger unnecessary failovers.

Goal:
Introduce a unified abstraction for host identity within CMAPI. Every host should have a single stable identifier that is stored and compared consistently. Hostnames and IPs should be treated as attributes of that identifier, not as identifiers themselves.

Proposed approach:
• Create a Host Address Manager as the canonical source of host identity.
• When adding a host, resolve it into: all known IP addresses (IPv4, IPv6) and all hostnames that resolve back from those IPs
• Assign a unique internal identifier to the host, which is used throughout CMAPI as the key.
• Expose APIs for components to query this manager for all known representations of a host (IPs, hostnames, aliases).
• Update cluster checks (e.g., ActiveNodes comparison) and failover logic to use this abstraction rather than raw hostnames/IPs.
• Later: Consider TTL-based refreshing for DNS lookups, to handle dynamic environments. Maybe we don't need it, it is a rare case.

Expected outcome:
• Consistent handling of hosts across components.
• Reduction of errors caused by mismatched hostname/IP representations.
• More robust failover and replication logic.
• Clear path for future improvements (e.g., IPv6 support).

High-level implementation approach:
We will introduce a dual-plane configuration:
• In the CMAPI, every host will be represented by a stable internal identifier (host_id). All resolution logic (forward/reverse DNS, filtering out local aliases, handling IPv4/IPv6, TTL refresh) will live here. CMAPI will store and use these identifiers consistently when checking Active/Desired/Inactive sets and other cluster logic.
• In the engine layer, we cannot refactor everything to IDs. For compatibility, the engine will continue to receive a “flattened” view of hosts as concrete IP addresses. This view will be generated automatically from CMAPI’s host records, so the engine does not see local aliases or inconsistent hostnames.
• The Host Manager in CMAPI acts as the adapter between these two layers: it accepts input (hostnames/IPs), resolves and validates them, assigns/returns a host_id, and produces both (a) the full identity object for CMAPI logic, and (b) the simplified address list for the engine.
• Backward compatibility: in existing configs on the CMAPI plane, we will transparently replace raw hostnames/IPs with host_ids. This means older configs remain valid (we can still parse user-provided hostnames/IPs), but internally they will be normalized and mapped to a host_id. For the engine plane, we will continue to output IPs exactly as before, so the C++ side does not need changes.

This way, CMAPI can evolve towards robust identity management without breaking the existing C++ code, while ensuring both layers use a consistent source of truth.