KAFKA-18230: handle not controller or not leader error in admin client

[showuon]

When admin client starts up, it'll get the metadata of the cluster. And when the admin client sends request directly to the controller (via --bootstrap-controller), it'll send the request to the active controller. But if there is a leadership change in the controller after the metadata request and before the target request sent, the request will fail immediately with NOT_CONTROLLER error or NOT_LEADER_OR_FOLLOWER error. It's because the requests that need metadata log change must need to do on the active controller. Instead of failing immediately, the admin client should catch the error and retry the metadata update to send the request again. Note, in some application, the admin client could exist for a long time to send multiple requests when needed, this case could happen more often.

In this PR, I handled NOT_CONTROLLER and NOT_LEADER_OR_FOLLOWER in the requests that allow talk to controller directly, and the controller will modify the metadata log, or requesting raft update, which must be done by the active controller. The APIs are:

1. createAcls
2. deleteAcls
3. alterConfigs
4. describeMetadataQuorum
5. addRaftVoter
6. removeRaftVoter

Committer Checklist (excluded from commit message)

• Verify design and implementation
• Verify test coverage and CI build status
• Verify documentation (including upgrade notes)

[mumrah]

@showuon #17881 adds a "triage" label to PRs from non-committers. Turns out this also affect committers if their membership visibility in the ASF GitHub org is not public. I added instructions for setting your membership visibility to public https://github.com/apache/kafka/blob/trunk/.github/workflows/README.md#pr-triage