[improve][broker] avoid creating new objects when intercepting

[mattisonchao]

Motivation

When we do performance testing on the cluster. we find an issue which causes creates many small objects.

Modifications

• replace the object with logic.

Verifying this change

• Make sure that the change passes the CI checks.

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 87.09677% with 8 lines in your changes are missing coverage. Please review.

Project coverage is 73.24%. Comparing base (bbc6224) to head (22b65d5).
Report is 312 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #22790      +/-   ##
============================================
- Coverage     73.57%   73.24%   -0.34%     
- Complexity    32624    32630       +6     
============================================
  Files          1877     1891      +14     
  Lines        139502   141617    +2115     
  Branches      15299    15542     +243     
============================================
+ Hits         102638   103722    +1084     
- Misses        28908    29873     +965     
- Partials       7956     8022      +66     

Flag	Coverage Δ
inttests	27.37% <0.00%> (+2.78%)	⬆️
systests	24.78% <0.00%> (+0.46%)	⬆️
unittests	72.25% <87.09%> (-0.60%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...er/intercept/BrokerInterceptorWithClassLoader.java	87.50% <87.09%> (-1.57%)	⬇️

... and 404 files with indirect coverage changes

[eolivelli]

From the data you pointed out it doesn't see a big deal to have that instance, there are many other cases.
Probably we shold drop ClassloaderSwitcher at all ?
It seems a code smell that in some cases we use it and sometimes not. I am pretty sure that at some point someone will come an revert this change because it sees that this code is different from the other codes that use NarClassLoader

[dao-jun]

Since BrokerInterceptor could execute in the message publish/consume calling chain, I think we should try our best to avoid object allocation.
I support the PR, maybe it smells not good, but, it could work better.

[dao-jun]

Otherwise, all the optimizations for memory/object allocation in the calling chain is meaningless: "It not a big deal to allocate objects/heap memories, let them GC"

[mattisonchao]

Since BrokerInterceptor could execute in the message publish/consume calling chai

this is the point here. :)
I observed 100k+ objects here in the tiny cluster.