[#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.3.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]

These comments fall into the "nit" category and aren't required but I was just thinking this might be a good time to use Optional. This is not on a hot path so it won't create a lot of extra objects to clean up so it might make it a bit cleaner (this comment applies for all the places looking up the ssl context is used with a ternary operator.)

return TransportFactorySupport.bind(brokerService, uri,
    Optional.ofNullable(sslContext).orElseGet(() -> brokerService.getSslContext()));

or

return TransportFactorySupport.bind(brokerService, uri,
                Optional.ofNullable(sslContext).orElse(brokerService.getSslContext()));

Using a helper method:

public SslContext getAppliedSslContext() {
   return sslContext != null ? sslContext : brokerService.getSslContext();
}

[cshannon]

I need to look at this more but this likely needs to be tweaked because sslContext isn't volatile

[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.