Micro 4.1.0 fails to start with Netty component mismatches

[Andy-Hay]

Describe the bug

java.lang.NoSuchMethodError: 'boolean io.netty.internal.tcnative.SSL.setCurvesList(long, java.lang.String[])'                                                   
      at io.netty.handler.ssl.ReferenceCountedOpenSslEngine.setSSLParameters
      at software.amazon.awssdk.http.nio.netty.internal.utils.NettyUtils.configureSslEngine                                                                       

The Netty core library in the image is calling SSL.setCurvesList() — a method that was added to netty-tcnative (the native OpenSSL binding) in a more recent release — but the netty-tcnative version bundled in the image doesn't have it. The two Netty components are mismatched, so TLS channel initialisation fails immediately, causing every S3 connection to be dropped before a single byte is exchanged.

This is a bug in the Micro 4.1.0 build. The fix needs to come from the Micro team (consistent netty-tcnative + netty-handler versions in the fat jar).

To Reproduce

Start up Micro 4.1.0 in K8s, pod crash loops with above error

Expected behavior

Micro to start cleanly

Environment (please complete the following information):

• OS: EKS K8s
• Version 1.33