[PIP 95][Issue 12040][broker] Decouple advertised listeners from bind addresses

[EronWright]

Master Issue: #12040
Related: #3501

Motivation

This PR decouples the advertised listener configuration from the broker bind addresses, and fixes a few places where the broker is assumed to have a plaintext cluster endpoint or conflates the TLS/plaintext endpoints.

The goal is to support a specific configuration, where the broker has an advertised listener corresponding to an Istio gateway, and the gateway terminates TLS (pulsar+ssl://broker1.gateway:6651/). Because Istio uses mTLS transparently within the mesh, the broker has only a plaintext server endpoint (pulsar://broker1.cluster:6650/). Without this patch, the broker rejects the configuration because it erroneously assumes that the broker should have a TLS binding to support a TLS advertised address.

This PR deprecates the PulsarService::getSafeBrokerServiceUrl method, which returns a plaintext endpoint if available, and a TLS endpoint otherwise. The resultant endpoint is then advertised to Pulsar clients but the scheme information isn't always considered. Observe that client code disregards the scheme in some cases:

pulsar/pulsar-client/src/main/java/org/apache/pulsar/client/impl/HttpLookupService.java

Lines 95 to 105 in d81b5f8

	if (useTls) {
	uri = new URI(lookupData.getBrokerUrlTls());
	} else {
	String serviceUrl = lookupData.getBrokerUrl();
	if (serviceUrl == null) {
	serviceUrl = lookupData.getNativeUrl();
	}
	uri = new URI(serviceUrl);
	}
	InetSocketAddress brokerAddress = InetSocketAddress.createUnresolved(uri.getHost(), uri.getPort());

Note that this PR is focused on the Pulsar protocol endpoints, not the REST API endpoints.

Modifications

• Remove validation logic that compares the advertised listener against the bind addresses.
• Deprecate PulsarService::getSafeBrokerServiceUrl and be explicit about which address is used.
• Update broker code to not assume there's a plaintext endpoint for a given advertised listener (it might be pure-TLS).

Verifying this change

• Make sure that the change passes the CI checks.

This change is already covered by existing tests, such as:

• MultipleListenerValidatorTest

Does this pull request potentially affect one of the following parts:

• The public API: yes

The information that is returned by the broker is slightly different in the case of a pure-TLS broker. In that case, lookup results (which consist of a pair of URLs) might not have a plaintext URL. In concept a client could break, though in practice this is unlikely since the broker didn't really work in such a configuration anyway.

Documentation

Need to update docs?

• no-need-doc

Internal changes.

[eolivelli]

LGTM

@codelipenghui @merlimat PTAL