Remove HTTPS workaround added in #6673

[mbien]

The problem will likely resolve itself (due to updates in tested gradle versions or other means), once it is working again, remove the workaround added in #6673

See first //TODO in MicronautGradleArtifactsImplTest and ProjectViewTest (c0f09c927b7a63ebc228156afc8e2ff35ec34b84)

[mbien]

found

System.setProperty("javax.net.debug", "ssl:handshake");

to be useful for SSL debugging. But it produces a lot of output with is mixed with the test output which is also a lot. Would be interesting to diff the two https handshake logs of the gradle Downloader with and without the workaround.

exception snippet taken from the PR:

Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:347)
	at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:186)
	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1511)
	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1421)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:456)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:427)
	at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:580)
	at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:201)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect0(HttpURLConnection.java:2830)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.followRedirect(HttpURLConnection.java:2742)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1869)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1525)
	at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:250)
	at org.gradle.wrapper.Download.downloadInternal(Download.java:129)
	at org.gradle.wrapper.Download.download(Download.java:109)

[mbien]

we can probably revert this now again. The problem seems to have some self healing properties as suspected ;)

I repeated some brute force testing in my clone to exclude that this has something to do with an JDK update release:

And since we already excluded before that it is os image related in any way (the image hash didn't change between the last good and the first bad run), it likely is nw infra related. Since I also could reproduce it locally back then, it likely was the gradle host config since this would exclude CI too.

cc @sdedic

[mbien]

sorry about the noise, I ran the wrong tests and got excited too fast.

[mbien]

higher priority than this would be to get gradle tests testable on 21+, since they are locked to JDK 17 atm. I still hope that things like this resolve themself via dependency updates.

Once the latest wrappers+gradle is used we can take another look. Also tracked via https://github.com/apache/netbeans/issues/7871