[#2132] Migrate SSL support away from ThreadLocal, support key alias and default to pkcs12

[mattrpav]

All wiring of transports now takes SslContext as a parameter, instead of 'magically' showing up as a ThreadLocal when needed.

This unlocks a lot of capabilities, including per-transportConnector SSLContext, per-networkConnector SSLContext and eventually auto-reloading of SSLContext.

• DefaultSslContext (remove active usage of ThreadContextSslContext)
• Default to stronger and now JDK-default keystore type: 'pkcs12'
• Add support for keyAlias
• Add per-connector sslContect
• Add per-networkConnector sslContext
• Add ComptibleSslContext to bridge Spring for a non-ThreadLocalSslContext
• Retain a ThreadContextSslContext class in case someone extended some part of the broker or client (add'l transport connector, etc) and needs a way to transition
• Unit test refactors

Merge plan: Squash all commits to one for v6.4.0 only (no backport)

[cshannon]

This is a pretty major refactor and needs to be reviewed carefully before merging. I assume this will not be backported and only be targeted for 6.3.0 due to the major changes.

@mattrpav - are there breaking API changes here? a quick look showed old methods delegating to the new ones so I don't think so but we don't want to break anyone who upgrades

[mattrpav]

@cshannon correct, this is only for 6.3.0.

The original SslContext is renamed ThreadLocalSslContext and remains if anyone needs previous behavior exactly.

The ComaptibleSslContext provides same method signature as the ThreadLocalSslContexr for historical compatibility for wiring of arrays v lists, but removes the ThreadLocal usage.

The DefaultThreadLocalContext becomes the new default.

This change removes all ThreadLocalSslContext usage and updates transportConnectors and networkConnectors to support having independent SSLContexts as needed. They all fall back to the broker-wide one as before, if an independent sslcontext is not configured.

[cshannon]

I did a quick browse of this and it makes sense to get rid of the thread local if possible but I need to do a deeper dive and try it out. I think there might be a couple things to tweak but overall I think this makes sense. The less thread locals we have the better and as you pointed out it gives us more flexibility in the future.

[cshannon]

I went through a lot of it but I stopped after I saw there were still several spots where logic could be consolidated and get rid of copy and paste, so that is my main feedback, to reactor to consolidate the logic around connection into one spot, unless there's something that makes it not possible

[cshannon]

LGTM now, assuming CI runs and passes. It's a big update so I expect we may have missed something minor but if we find a tweak to make later we can push a follow on PR.

[cshannon]

@mattrpav - CI found a real failure, the DiscoveryTransportBrokerTest failed

It took me a while to track it down as it was tricky but it turns out during the recent refactor an override got missed, causing the DiscoveryTransportFactory to create an instance of FailoverTransport instead of DiscoveryTransport (that then contained the FailoverTransport).

The fix is pretty simple, I created a quick PR: mattrpav#8