KAFKA-14588 ConfigEntityName move to server-common

[nizhikov]

This PR is part of "KAFKA-14588 Move ConfigCommand to tools".
ConfigCommand depends on ConfigEntityName class.
This PR moves ConfigEntityName to "server-commons" module.

Changes are relatively huge so it make sense to review then separately from other.

Committer Checklist (excluded from commit message)

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

[kamalcph]

LGTM!

[nizhikov]

Hello @ijuma @jolshan
Can you, please, take a look?

This PR simply moves ConfigEntityName.
It's required, because ConfigCommand depends on ConfigEntityName and command itself will be moved to tools module.

[nizhikov]

@mimaison Can you, please, take a look.

[mimaison]

Running the tests locally I get this failure which seems related:

ConfigCommandTest.shouldNotSupportAlterClientMetricsWithZookeeper()
rg.opentest4j.AssertionFailedError: expected: <client-metrics is not a known entityType. Should be one of List(topics, clients, users, brokers, ips)> but was: <client-metrics is not a known entityType. Should be one of [topics, clients, users, brokers, ips]>
	at app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
	at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1141)
	at app//kafka.admin.ConfigCommandTest.shouldNotSupportAlterClientMetricsWithZookeeper(ConfigCommandTest.scala:1765)

[nizhikov]

Test failure was fixed by 417338a
I merged latest trunk to PR so it must be OK now.

[ijuma]

It's a bit weird to move stuff like this to server-common. Is this used by anything outside of tools?

[nizhikov]

@ijuma

Is this used by anything outside of tools?

AFAICS yes.

DymamicConfig, ClientQuotaMetadataManager, DynamicConfigPublisher to name a few.
These classes works inside the broker isn't it?

[ijuma]

You're right. The weird part is actually the fact that ConfigCommand relies on this detail instead of using the relevant public apis. I guess it's partly due to the remaining zk code. Seems ok to go with this approach for now and clean it up once we branch for 4.0.

[mimaison]

Yes I expect we'll be able to remove that when we remove ZooKeeper. In the meantime, these PRs are helpful to move the commands to the tools module.

[ijuma]

Sounds good.

[nizhikov]

Double checked test failures.
Looks like not related to the changes.

[mimaison]

LGTM, thanks