NETWORKING: Fix Netty Leaks by upgrading to 4.1.28

[original-brownbear]

• Upgrade to 4.1.28 since the problem reported in [CI] SslIntegrationTests fail with Netty buffer leak #32487 is a bug in Netty itself (see Possible buffer leak in SslHandler? netty/netty#7337)
• Fixed other leaks in test code that now showed up due to fixes improvements in leak reporting in the newer version
• Needed to extend permissions for netty common package because it now sets a classloader at runtime after changes in netty/netty@63bae09
• Adjusted forbidden APIs check accordingly
• Closes [CI] SslIntegrationTests fail with Netty buffer leak #32487

[elasticmachine]

Pinging @elastic/es-core-infra

[jasontedor]

LGTM. If CI is happy, I am happy. This is so much better than the circus we had in #31232.

[original-brownbear]

Jenkins test this
(CI was green, packaging test didn't trigger for some reason)

[Tim-Brooks]

LGTM

The code does not really bother me since it is in unit tests. But it looks like netty does have a facility for releasing RCs in testing without try/finally.

http://netty.io/wiki/reference-counted-objects.html

public void testSomething() throws Exception {
    // ReferenceCountUtil.releaseLater() will keep the reference of buf,
    // and then release it when the test thread is terminated.
    ByteBuf buf = ReferenceCountUtil.releaseLater(Unpooled.directBuffer(512));
    ...
}

I don't know how effective that is. But something to maybe look at in future fixes.

[original-brownbear]

@tbrooks8 thanks!

I'm just fixing those tests, so the leak detector doesn't go red :) io.netty.util.ReferenceCountUtil#releaseLater(T) is deprecated (and in my experience/opinion rightfully so). It's just taking too much memory potentially because buffers are kept around for the whole duration of the test run which can really add up in unexpected ways.