KAFKA-19470 Avoid creating loggers repeatedly to affect the performance of request processing

[terrytlu]

fix the issue mentioned https://issues.apache.org/jira/browse/KAFKA-19470, to avoid the jdk11 + lo4j2 performance issue.
Optimize the trait Logging, introduce a static Map object to cache the same class loggers.

The testing strategy is:
Create two instances, their classes inherit from the trait Logging, these two class instances will have the same variable logger, that is, the StackWalker method will not be called twice

[terrytlu]

hello @ijuma @divijvaidya , could please help review this pr 🙏

[gaurav-narula]

Thanks for the PR! From the discussion in the previous PRs (#9910 (comment) and #13949 (comment)), one of the reasons to limit the change to frequently instantiated classes was an understanding that the Logging trait isn't a good-pattern.

Given there's a lot of refactoring in progress specially around the Scala code, should we instead look at moving away from the Logging trait?

[terrytlu]

Thanks for the PR! From the discussion in the previous PRs (#9910 (comment) and #13949 (comment)), one of the reasons to limit the change to frequently instantiated classes was an understanding that the Logging trait isn't a good-pattern.

Given there's a lot of refactoring in progress specially around the Scala code, should we instead look at moving away from the Logging trait?

Moving away from the Logging trait would require lots of work to refactor, every class that needs to log would need to create an object containing the logger. Not an easy proposal to implement I think... @gaurav-narula

[github-actions]

A label of 'needs-attention' was automatically added to this PR in order to raise the
attention of the committers. Once this issue has been triaged, the triage label
should be removed to prevent this automation from happening again.