Initially the XMPPTrustManager queried getServiceName from the
ConnectionConfiguration and used that for certificate validation. This is a
bug, because the serviceName corresponds to the hostname of the jabber id. That
is, if we're trying to connect for account foo@bar.com it corresponds to
bar.com.

However, we are properly doing a SRV lookup to see which server hosts the
actual XMPP server for bar.com, which may be on a different hostname. For
example, everyone hosting their XMPP at fastmail.com will have their XMPP
server on chat.messagingengine.com. The XMPPTrustManager will then try to
verify the server's certificate of chat.messagingengine.com against the bar.com
it expects, which will obviously fail. This issue renders it impossible for
anyone using a 3rd part XMPP server to connect to their account.

The correct approach is to use the hostname returned by the SRV lookup as the
hostname checked by XMPPTrustManager. That is, if our SRV lookup for bar.com
returns chat.messagingengine.com as the XMPP server, we should validate that
the certificate corresponds to chat.messagingengine.com, NOT bar.com