Support FQDN

[Samunroyu]

Motivation

Currently Pegasus can't completely support Fqdn in all the situations.
For instance, the server-side Bulk Load feature needs to support FQDN, and the server-side log output and HTTP interface displays must also use FQDN. Both Java and Go clients require FQDN support as well. All the aforementioned features must take scenarios with authentication enabled into account.

Implementation

The new design is centered around the principle of on-demand (lazy) resolution, with a clear distinction between a node's low-level RPC address and its high-level hostname.

rpc_address vs. host_port

• rpc_address: This remains the fundamental, IP-based address used for low-level RPC communication. It is considered the source of truth for a node's current network location.
• host_port: This represents the node's stable hostname and port (e.g., node-1.pegasus.cluster.local:34801). This field is now treated as an optional, cacheable representation of the rpc_address.

On-Demand Resolution via Helper Macros

To abstract the resolution logic and ensure a consistent implementation across the codebase, a set of C++ helper macros were introduced in src/rpc/rpc_host_port.h. These macros intelligently fetch the host_port and fall back to resolving it from the rpc_address if it's not already present.

• GET_HOST_PORT(obj, field, target): Retrieves a single host_port for a field (e.g., primary).
• GET_HOST_PORTS(obj, field, target): Retrieves a vector of host_ports for a list field (e.g., secondaries).

This approach centralizes the address resolution logic, hiding its complexity from the rest of the application and preventing inconsistent implementations.

Task list

WIP

Server

• feature(FQDN): Bulk Load support Fqdn #2352

Java Client

• feature(FQDN): Java Client support Fqdn #2353

Go Client

• feature(FQDN): Go Client support Fqdn #2354