HDDS-15176. Ozone SCM fails to start when gRPC cipher policy list includes unsupported cipher

[dombizita]

What changes were proposed in this pull request?

The gRPC server TLS setup applies the configured cipher list directly when building the Netty OpenSSL context. If any configured cipher is unsupported (and there is no supported cipher in the list before that), TLS context creation throws an error and SCM startup fails. Unsupported ciphers in the configured list should be filtered out and service startup should continue if at least one valid cipher remains.

Instead of this:

sslContextBuilder.ciphers(securityConfig.getGrpcTlsCiphers()); 

It should use Netty SupportedCipherSuiteFilter.INSTANCE when applying configured cipher lists in gRPC server TLS context builders:

sslContextBuilder.ciphers(
    securityConfig.getGrpcTlsCiphers(),
    SupportedCipherSuiteFilter.INSTANCE); 

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-15176

How was this patch tested?

Added a unit test for this scenario, which was failing before applying the fix. Green CI on my fork: https://github.com/dombizita/ozone/actions/runs/25378217331

[dombizita]

@octachoron could you please review it? thanks!

[octachoron]

Points double-checked (most of which we discussed offline as well):

• Silently removing cipher suites still keeps the server in line with the user-supplied configuration (and one specific suite is selected for each connection anyway).
• This is a convenient way to filter out exactly the unsupported suites, more so than asking users to manage the list externally.
• No specification seems to exist that requires failing to start when the list contains unsupported cipher suites, so we should be good here too. (I did not find any such requirement either, and there is no test for it.)
• Setting the cipher list is idiomatic, and the new test follows this idiom, so it should effectively cover the whole change.
• Netty usage looks good.
• All four usages of the configuration parameter are covered.

There is one edge case where we may see surprises: when more than one TLS version is enabled, and one of them is left with zero ciphers after the filter. This can have different results, possibly depending on the selected SslProvider:

• A hard error despite having allowed and valid combinations in the configuration, like with openssl ciphers -ciphersuites TLS_AES_256_GCM_SHA384 -V ''.
• Falling back to defaults on the given TLS version, like with openssl ciphers -ciphersuites TLS_AES_256_GCM_SHA384 -V.
• Disabling the corresponding TLS version.
• Something else I am not considering.

Are you aware of any reason to prefer a specific one, or anything that guarantees the outcome? (I am checking too, but maybe this has been investigated already.)