Issue #12428 - ALPN Processor for Bouncy Castle FIPS

[lucarota]

Ciao,

I added a new ALPNProcessor for Bouncy Castle TLS FIPS version, both client and server, based on the JDK9ServerALPNProcessor that resolves the issue #12428.
Now all the tests should be correct.

Regards,
Luca Rota

[sbordet]

@lucarota my understanding is that the API used are those of the JDK, so the configuration of BouncyCastle FIPS is orthogonal.

What I mean is that I would prefer this PR to have dependencies on bctls rather than anything FIPS, since whether one wants to use FIPS or not is just matter of external configuration.
Please correct me if I am wrong.
Is there a specific reason you used FIPS?

BC FIPS code also does not appear to be in a public repository (I could not find it), so I'd stick with what's in GitHub.

@lachlan-roberts, on top of this PR we should refresh jetty-keystore which is still using the old jdk15to18 jars.

@jmcc0nn3ll I assume there is no problem with the BouncyCastle license? It is a MIT license, and we should have already cleared it for jetty-keystore, but I would like to be sure, as this PR would make use of BouncyCastle for Jetty's TLS, rather than just use BouncyCastle in the jetty-keystore tool to generate a KeyStore on-the-fly.

[joakime]

@jmcc0nn3ll I assume there is no problem with the BouncyCastle license? It is a MIT license, and we should have already cleared it for jetty-keystore, but I would like to be sure, as this PR would make use of BouncyCastle for Jetty's TLS, rather than just use BouncyCastle in the jetty-keystore tool to generate a KeyStore on-the-fly.

We would need to put the license block for BouncyCastle into the jetty-keystore.mod file, and have users accept it. (like all other non-eclipse licensed modules we have now)

[jmcc0nn3ll]

@gregw @joakime It should be run through the eclipse IP process and go from there, if it can be included then we are golden, if not then we'll have to do the agreement thing.