"PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException" - caused by HttpUrlConnector which relies on DefaultSSLSocketFactory value which is not a constant"

https://github.com/eclipse-ee4j/jersey/blob/master/core-client/src/main/java/org/glassfish/jersey/client/internal/HttpUrlConnector.java#L302-L304

`HttpUrlConnector` sets the custom SSLFactory only when the one in the current `HttpsURLConnection` instance is the default one:

```
if (HttpsURLConnection.getDefaultSSLSocketFactory() == suc.getSSLSocketFactory()) {
// indicates that the custom socket factory was not set
suc.setSSLSocketFactory(sslSocketFactory.get());
}
```

However, there is no guarantee that `HttpsURLConnection.getDefaultSSLSocketFactory()` remains a constant. Furthermore, there is an open bug about this issue:
https://bugs.openjdk.java.net/browse/JDK-8160347

This leads to the situation when the underlying `HttpsURLConnection` doesn't receive a custom SSLSocketFactory from the client.

The issue is certainly related to this one: https://github.com/eclipse-ee4j/jersey/issues/3293 but the fix was not proposed or has not been merged, so the issue is still remains.

Several screenshots with an evidence of this issue I've caught in debug.
On this screenshot we see that the current instance of `HttpUrlConnector` has a custom `SSLSocketFactory` instance with a custom `TrustManager` with one trusted certificate.

The second screenshot demonstrates, that the `uc` object still has a default `SSLSocketFactory` with the default `TrustManager` containing 88 certificates.

The final screenshot shows that even though both `HttpsURLConnection.getDefaultSSLSocketFactory()` and `suc.getSSLSocketFactory()` have the same `SSLContext`, the instances themselves are not equal.

This causes apparently `"PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException"` error because of the wrongly configured truststore.