[client] Support specifying rack when adding/removing server tags in Admin API

[LiebingYu]

Purpose

Linked issue: close #2889

Brief change log

Tests

API and Format

Documentation

[LiebingYu]

Hi @swuferhong, PTAL!

[swuferhong]

Hi, @LiebingYu, thanks for your contributions. I left some comments.

[swuferhong]

removeServerTagByRack() only resolves IDs from getServerNodes(), which returns the currently alive TabletServers. Once all servers in a rack have gone offline, this method resolves an empty ID list and returns success without removing their tags.

This is asymmetric with removeServerTag(List<Integer>, ServerTag): the Coordinator-side processRemoveServerTag() explicitly tolerates a missing server and still removes its tag. Therefore, a tag applied before decommissioning cannot later be cleaned up by rack after the physical host has gone offline; it remains in ZooKeeper and coordinatorContext until the caller removes it explicitly by server ID.

Please preserve enough rack-to-server information to resolve tagged offline servers. Moving rack resolution to the Coordinator is preferable, but it also requires persisting the rack association—for example, storing the rack together with the server tag or retaining historical server metadata—because the live registration is removed when the server goes offline. If this API is intentionally limited to alive servers, that limitation should at least be stated explicitly in its Javadoc and user documentation.

[LiebingYu]

Thanks, this is a valid point. I’m intentionally keeping removeServerTagByRack() as a one-shot convenience selector over the Coordinator’s currently registered TabletServers, rather than introducing persistent rack membership history.

Consequently, it does not remove tags from servers that are already offline or no longer belong to their former rack. Those tags remain persisted by server ID and should be cleared with removeServerTag(serverIds, tag), especially before a server ID is reused.

I have documented this limitation explicitly in the JavaDoc and user documentation. The external cordon prevents new servers from entering the rack during decommissioning, but does not change this removal limitation.

If removing offline servers by rack is required as part of the API contract, I think that should be handled by a separate rack-history/policy design rather than adding that state implicitly in this PR.

[platinumhamburg]

LGTM +1.