Support brokerName in request protocol

[drpmma]

FEATURE REQUEST

1. Support brokerName in request protocol.
2. brokerName is a higher-level abstraction than brokerAddress and should be taken in request.
3. Related components should know request-target by brokerName such as logic queue extension, envoy-like cloud-native gateway, or even more separate computing and storage to decouple computing from current broker logic.
4. Detail request code: PULL_MESSAGE, UPDATE_CONSUMER_OFFSET, QUERY_CONSUMER_OFFSET, SEARCH_OFFSET_BY_TIMESTAMP, GET_MIN_OFFSET, GET_MAX_OFFSET.

[ni-ze]

BrokerAddress can be used as a router, I do not get why do you need brokerName.

[duhenglucky]

@drpmma In favor of this recommendation, the entire Remoting layer is currently IP oriented. Using broker names instead of IP can better hide the underlying state of the broker, especially the abstraction of logical resources brought by logical queues and other features. So would you like to submit a RIP for this proposal?

[drpmma]

BrokerAddress can be used as a router, I do not get why do you need brokerName.

BrokerAddress is not taken in remoting layer protocol while is just a target. So the secondary components don't have the information to route to other brokers, that's why we need a BrokerName

[lizhanhui]

+1 for the change. IP-centered strategy suffers a lot in the era of cloud and container orchestration. We need logical representation to adapt to this trend.

[chenzlalvin]

Not only brokerName, the queueId also need abstraction, unbind with specific physical node

[drpmma]

Now that bname is supported in RpcRequestHeader, related RPC can use this field to implement.