Container.connect doesn't set virtual_host by default, making peer verification harder than it should be

In 0.35 proton-c started to default to PN_SSL_VERIFY_PEER_NAME in client mode, which is good. However, it seems that it does not (by default) extract the peer name from the URL, so a connection can not be established, even if the certs and everything matches, as there is no name to verify against.

Looking at the Ruby examples (https://qpid.apache.org/releases/qpid-proton-0.35.0/proton/ruby/examples/ssl_send.rb.html), you suggest to roll back the default VERIFY_PEER_NAME to ANONYMOUS_PEER:

    ssl_domain = Qpid::Proton::SSLDomain.new(Qpid::Proton::SSLDomain::MODE_CLIENT)
    ssl_domain.peer_authentication(Qpid::Proton::SSLDomain::ANONYMOUS_PEER)
    c = container.connect(@url, { :ssl_domain => ssl_domain })

And indeed, dropping the ANONYMOUS_PEER fails the connection attempt.

Instead, we can explicitly set the virtual_host of the connection, thus allowing the PEER_NAME verification to succeed:

    ssl_domain = Qpid::Proton::SSLDomain.new(Qpid::Proton::SSLDomain::MODE_CLIENT)
    c = container.connect(@url, { :ssl_domain => ssl_domain, :virtual_host => URI.parse(@url).host })

However, I think this is cumbersome and makes users lifes harder than they should be.

If container.connect would automatically set the virtual_host to the host part of the URL (unless it was defined by the user), SSL verification would just work.

FWIW, I only tested this all with the Ruby bindings on Ruby 2.7, OpenSSL 1.0.2k-21.el7_9.x86_64 (CentOS 7), so this might behave differently on other environments.