private-address is set as a hostname for amqp relation instead of a local hostname

[Dmitrii Shcherbakov]

In order to implement inter-node TLS termination for secure cluster connectivity and also for clients to initiate and negotiate secure connections to rabbitmq servers (while still using password auth) X.509 TLS certificates need to contain Subject Alternative Name fields (https://tools.ietf.org/html/rfc5280#section-4.2.1.6) with multiple hostnames (one per rabbitmq host).

https://www.rabbitmq.com/ssl.html#peer-verification

TLS clients generally follow https://tools.ietf.org/html/rfc2818#section-3.1 and validate that a hostname they connect to is present in either Subject field as a CN or in SubjAltName field of a server certificate they are presented with.

Those names are currently retrieved via gethostname(2) in the charm code from the current UTS namespace and are also exchanged between different rabbitmq-server units and added to /etc/hosts (presumably to avoid DNS resolution dependency). This is done only for "cluster" relation between rabbitmq peers.

For rabbitmq clients this is not the case and they use a list of "private-addresses" (rabbit uses get_unit_ip which relies on network spaces but a hostname is needed here). This is both because rabbitmq does not use a hostname and passes an IP address and also because charm-helpers explicitly use private-address (the same is valid for both classic and reactive charms).

https://pastebin.canonical.com/p/Fxrj4cjxN9/
rabbit_hosts = 10.232.4.157,10.232.4.168,10.232.4.195

cluster relation handling
https://github.com/openstack/charm-rabbitmq-server/blob/stable/18.02/hooks/rabbitmq_server_relations.py#L317-L322
https://github.com/openstack/charm-rabbitmq-server/blob/stable/18.02/hooks/rabbit_utils.py#L985-L990 (get_unit_hostname calls socket.gethostname which gives you a hostname the way it is viewed in the current UTS namespace)
https://github.com/openstack/charm-rabbitmq-server/blob/stable/18.02/hooks/rabbitmq_server_relations.py#L374-L375

amqp relation handling
https://github.com/openstack/charm-rabbitmq-server/blob/stable/18.02/hooks/rabbitmq_server_relations.py#L228-L231

https://github.com/juju/charm-helpers/blob/v0.18.6/charmhelpers/contrib/openstack/context.py#L532-L543

In this case clients will connect via IP addresses and, even if the SubjAltName field contains all rabbitmq hostnames, validation will fail due to a mismatch.