Make it easier to perform peer verification when TLS is enabled

[michaelklishin]

Background

A discussion about a more secure TrustManager implementation used by default when ConnectionFactory#useSslProtocol() (the 0-arity version) is used has been going on for a few years now, see e.g. in #226. @acogoluegnes and I have some specific ideas that won't trip up beginners and open the flood gates of TLS configuration questions on our tiny team.

Certificate Validity Checks

Default TrustManager and any future versions should perform certificate validity checks. Most TLS implementations would reject expired certificates by default. This should not make it any harder for beginners to get started and IMO is a no-brainer improvement.

Default JDK Certificate Store Option

As suggested in #226, it is possible to use default JDK certificate store instead of a custom one.
Our research suggests that with a null TrustManager the default/installed security provider will be used by default. In any case, we could provide a convenient way to do this.

Server Hostname Verification using SAN (Subject Alternative Name) and CN (Common Name)

Peer verification means at least 2 different types of checks in practice. One common thing that's
now covered in an HTTPS RFC is verification of server certificate's' SAN and CN (as a fallback) against the target hostname.
As of JDK 7 there is a way to enable such checks without implementing a TrustManager. Also, before JDK 7 TrustManagers didn't have access to the TLS socket information. It remains to be
decided whether we want to provide a custom implementation for JDK 6 which RabbitMQ Java client 4.x still supports 😭.

Unfortunately the peer verification algorithm has subtle differences between implementations, which can greatly complicate things for the user and increase support load on our team.

Documentation Improvements

Some parts of the RabbitMQ TLS guide have been reviewed very recently but others haven't been touched for a few years. It's worth revisiting the parts that cover peer verification in Java.

[acogoluegnes]

After some investigations, it appears that the TLS handshake performed by Java doesn't enforce hostname verification by default. Hostname verification must be explicitly enabled, so #398 provides a way to easily enable it (this isn't the default to preserve backward compatibility). This works for Java 7 and more, for Java 6, an extra hostname verification step must be added after the handshake.

Regarding server certificate validity, the check is performed by JDK TrustManager implementation.