Rackaware placement policy support local node awareness by hostname

[hangc0276]

Motivation

Rack-aware placement policies enable preference for bookies that reside in the same rack as the bookie client.

• Initiate local node by resolving the rack information
  

  bookkeeper/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/RackawareEnsemblePlacementPolicyImpl.java

  Lines 207 to 215 in 5b5c053

  	if (!ignoreLocalNodeInPlacementPolicy) {
  	try {
  	bn = createDummyLocalBookieNode(InetAddress.getLocalHost().getHostAddress());
  	} catch (IOException e) {
  	LOG.error("Failed to get local host address : ", e);
  	}
  	} else {
  	LOG.info("Ignoring LocalNode in Placementpolicy");
  	}

• When generating new ensembles for a ledger, the selecting algorithm will set the localNode's rack to curRack and select one bookie from curRack first
  

  bookkeeper/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/RackawareEnsemblePlacementPolicyImpl.java

  Lines 420 to 426 in 5b5c053

  	if (null == prevNode) {
  	if ((null == localNode) || defaultRack.equals(localNode.getNetworkLocation())) {
  	curRack = NodeBase.ROOT;
  	} else {
  	curRack = localNode.getNetworkLocation();
  	}
  	} else {

However, when resolving the local node's rack information, we use IP to resolve the rack name, which is unfriendly with k8s deployment.

bookkeeper/bookkeeper-server/src/main/java/org/apache/bookkeeper/client/RackawareEnsemblePlacementPolicyImpl.java

Line 209 in 5b5c053

bn = createDummyLocalBookieNode(InetAddress.getLocalHost().getHostAddress());

In k8s deployment, we usually use the hostname as bookieId and Pulsar broker name instead of IP, because the IP will be changed when the pods migrated to other nodes.

Modification

In order not to bring break change to the current behavior, I introduced a flag useHostnameResolveLocalNodePlacementPolicy in the BookKeeper client configuration to control whether to use the hostname to resolve the bookie client's local node rack information. The flag is false by default, which is the same behavior as the current logic.

Due to this PR doesn't introduce any break changes, I think we can cherry-pick it back to the patch releases (branch-4.14, branch-4.15 and branch-4.16)

[hangc0276]

@horizonzy Please help take a look, thanks.

[horizonzy]

LGTM.