v6: Custom TrustStore

[bevzzz]

Resolves #420

This PR allows users to pass their custom SSL certificates to WeaviateClient.

Technically, this can already be achieved by overriding the default TrustStore that Java uses by passing -Djavax.net.ssl.trustStore=/path/to/custom/truststore.p12, but that approach is rather crude, because it disregards default cacerts.

The "supply chain" for SSL certificates goes something like this:

truststore.file --> KeyStore --> TrustManagerFactory --> SSLContext

The simplest thing would be accepting an SSLContext from the user. But we need to send both HTTP and gRPC requests under the hood, which we do using 2 different libraries, and they both have their own "SSL context" abstraction.

So the next best thing is TrustManagerFactory. Both javax.net.ssl.SSLContext and io.netty.handler.ssl.SslContext can be configured to use a custom TrustManagerFactory. It also offers the users quite a lot of flexibility in terms of how and where do they get the certificates from.

The usage is pretty straightforward:

// Load custom certs in the TrustManagerFactory
TrustManagerFactory tmf;
try (var keys = new FileInputStream("/path/to/custom/truststore.p12")) {
    KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
    trustStore.load(myKeys, "secret-password".toCharArra());

    tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
    tmf.init(trustStore);
}

// Create WeaviateClient
var client = WeaviateClient.custom(
    conn -> conn
        .httpHost(...).httpPort(...)
        .grpcHost(...).grpcPort(...)
        .trustManagerFactory(tmf)
);

---

You may read the example above and think: "couldn't we just accept that file path and the password and do the rest ourselves"? I prefer not to because:

1. We don't want to handle/require passwords to users' certificates
2. Working on the file-path level takes away the flexibility of programmatically configuring a TrustStore

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Secrets	0   0   0   0	View in Orca

[bevzzz]

Test pipeline is failing because Weaviate instance running in DefaultGrpcTransportITest is does not have TLS enabled. I think.

[bevzzz]

From our discussion with @Dabz:

• this solution will work for users that only need to configure a custom truststore
• for next iterations we should look into providing a higher-level abstraction like SSLSocketFactory / SSLEngine / SSLContext (for example, Kafka's DefaultSslEngineFactory)

These are powerful security mechanisms that advanced users will probably want to have.