TlsHttpClientConfigurator is incorrectly packaged under `testing`

[k-wall]

Production class in the wrong package - Class TlsHttpClientConfigurator should not be packaged under io.kroxylicious.testing.kms.tls.

Originally posted by @robobario in #4043 (comment)

[ashoksmore]

Hi @k-wall , I’d like to work on this. Plan is to move TlsHttpClientConfigurator (and its supporting classes) from io.kroxylicious.testing.kms.tls to io.kroxylicious.kms.tls, update imports across the KMS providers, and adjust the CHANGELOG. Does io.kroxylicious.kms.tls sound right given the split-package constraint with io.kroxylicious.proxy.tls?

[SamBarker]

Hey @ashoksmore I'll assign you the issue.

I wonder if io.kroxylicious.kms.http.client might be a better package making it io.kroxylicious.kms.http.client.TlsHttpClientConfigurator? The InsecureTrustManager & SslConfigurationException would move in similar fashion. (@k-wall is there a reason it was called SslConfigurationException and not TlsConfigurationException, I think it would make sense to be consistent about our usage even if the industry is all over the shop).

There is one more thing to look at as part of the move. TlsHttpClientConfigurator is currently part of the kroxylicious-kms-tls-support module., I can see arguments both ways for keeping that name and moving to a new more http-client focused one, but I think we leave it as is for now. Happy with that @k-wall @robobario ?

[robobario]

There is one more thing to look at as part of the move. TlsHttpClientConfigurator is currently part of the kroxylicious-kms-tls-support module., I can see arguments both ways for keeping that name and moving to a new more http-client focused one, but I think we leave it as is for now. Happy with that @k-wall @robobario ?

Yep sounds good to me.

I think it might make sense in future to orient the module around building the JDK HttpClient and break the dependency on the jackson config model. So it could offer a builder type API for building up a JDK client with whatever TLS configuration we need. We have (in principle) agreed that we want to move away from shared jackson Tls config classes, so I imagine in future we will want each KMS to have its own config records but a common way to build up the JDK HTTP client with the features it needs. We could rename the model at that point, currently it really is just about TLS.