As a developer, I want to better corner sad paths for broker connections with unit tests

[james-d-brown]

Given a broker connection factory that tests and establishes broker connections
When the factory cannot establish a connection for any reason, such as a tls failure
Then there should be adequate unit tests to corner the sad paths (as well as the happy paths)

[james-d-brown]

Issue originally reported in Redmine ticket #133252-68 whereby the BrokerConnectionFactory reported (logged) a successful connection on which the tls handshake subsequently failed.

This ticket has two parts. First part is easy, add some unit tests for a happy path and basic sad path whereby the connection url/port is incorrect. I predict both of those tests will pass with the existing codebase.

Second part relies on tls working for broker connections. Once working, we can add a sad path with a tls failure, which will will presumably fail. Why? Based on the conversation in the above Redmine ticket, probably because the BrokerConnectionFactory is creating the connection object, which performs some subset of connection tests, such as presence/availability of the host, but does not start the connection (connection::start), which initializes the connection for messaging and presumably performs some other subset of connection checks, which includes initiating the tls handshake.

[james-d-brown]

Doing the first part and then putting this on hold, pending work on enabling tls for (events)broker connections, which is Redmine ticket #133252.

[james-d-brown]

Second part of this is on hold until we have tls working on the eventsbroker, at which time we can hopefully create both a happy and a sad path test for it.