TestRabbitMessaging breaks in lander

RabbitMQ seems to be saying it's not able to start because the address is already in use:

  ... {cannot_listen,{0,0,0,0,0,0,0,0},48258,eaddrinuse}

This might be an avenue for reproducing the bug.

The problem is tangled, afaict. In rabbitfixture:

- RabbitMQ is started on all addresses; the hostname attribute on
  RabbitServerResources doesn't actually seem to have an effect.

- RabbitServerResources.fq_hostname always uses socket.gethostname()
  instead of the hostname attribute. I think this was required because
  the server was starting up on all addresses rather than one.

- allocate_ports() only binds to localhost, not the address on which
  the RabbitMQ server is going to be brought up on. There's nothing
  preventing the port from being in use on any other address.

I think the fix will look like:

- Only start RabbitMQ on the specified address. The environment
  variable RABBITMQ_NODE_IP_ADDRESS can be used to do this.

- Change fq_hostname to use the configured hostname.

- Change allocate_ports() to take an address parameter, and pass in
  the configured hostname when using it.

I've just tested lp:~allenap/maas/rabbitmq-fixture-robustness on Julian's landing host, and it appears to fix the issue.

Released; it's a change that affects the test suite only.