Bug fix: Corrected exception propagation in protocol negotiators exception handling code

[ok2c]

@rschmitt I think I was working on the Conscrypt security provider upgrade when I had a case of Conscrypt quietly dying on me without leaving a trace in the logs. I no longer remember the exact combination of factors causing Conscrypt TLS initialization to fail before it was even going into the handshake sequence, but it was really something super unusual.

At this point I believe it is best just to remove the call to the exception callback.

[rschmitt]

Do we want to continue supporting Conscrypt the way we currently are, i.e. as a special case with dedicated code paths etc? I suspect that the current integration has been obsolete since Java 8 Maintenance Release 3, which backported ALPN and TLSv1.3. We should be able to just use the JDK's default crypto provider. This would actually simplify testing with a broader variety of crypto providers, such as ACCP.

[rschmitt]

Additionally, it may be a good idea to pass LoggingExceptionCallback.INSTANCE into these classes. A reference to the configured IOReactor exception callback should probably not escape the IOReactor code. That would make it trivial to verify that it's only being called where and when it should be.

[rschmitt]

I cherry-picked this commit to 5.4.x.

[ok2c]

Do we want to continue supporting Conscrypt the way we currently are, i.e. as a special case with dedicated code paths etc? I suspect that the current integration has been obsolete since Java 8 Maintenance Release 3, which backported ALPN and TLSv1.3. We should be able to just use the JDK's default crypto provider. This would actually simplify testing with a broader variety of crypto providers, such as ACCP.

@rschmitt Conscrypt works quite nicely as a drop-in replacement for the standard security provider with Java 11 onward. For some reason the same procedure does not work correctly with the latest Java 8.

We can drop the special handling of Conscrypt once we drop support for Java 8

[ok2c]

@rschmitt There is a AlpnTests test suite in core that exercises the ALPN handshake with various JSSE setups. You can reproduce the issue using that test suite but Conscrypt does support Mac or does not work with Mac. You would need a Linux box for that.

[rschmitt]

For some reason the same procedure does not work correctly with the latest Java 8.

Conscrypt's focus seems to be Android, so that's not surprising. Maybe they have a pre-MR3 compatibility baseline, or maybe they just never got around to it. Either way, I'm not in any hurry to drop Java 8 support. The only issue I foresee is that Intel Macs are going to become increasingly hard to come by, and I think Rosetta2 is being phased out next year, so we may have bitrot issues since we can't test Conscrypt+Mac.