Bug 1269430

Description of problem:
On the first host we explicitly ask the user which interface he want to use for the management bridge.
Then we directly call setupNetworks on vdsm in order to be able to bootstrap a virtual machine to install the engine on; this happens before having an engine VM.
When the engine is ready, hosted-engine-setup calls host.add on the engine REST API and this triggers host deploy to close the loop.
Host-deploy will simply find an already existing bridge (the one we created to bootstrap the VM) and it just uses that.

On additional hosts we still let the user select an interface but then we just call host.add. Now it's up to host-deploy to create the bridge cause it's not there on fresh hosts.
In the past (<= 3.5.3 I think) we were adding the host using the IP address of the selected nic as the host address and so host-deploy will contact it there and creates the bridge on that interface.
Due to an issue on the cert signing then we decided to move to have the host certs being signed on the hostname and not on the IP address and so we are now adding the host using its fqdn.

So now the engine resolves that fqdn and host-deploy creates the bridge on the interface with the IP that has been resolved by the host.
This still makes sense and it's basically what happens when you add a regular (not HE) host from the web ui the issue is that we let the user specify an interface for the management bridge but than we ignored it.

So now we have two alternatives:
1. directly create the bridge on the interface specified by the user before calling host.add as we do for the first host
2. simply remove that messy question for additional hosts behaving as the engine does for regular hosts. The user will implicitly select the interface just configuring his networking or he will fix the configuration as he does for regular hosts.  

I'm for option 2


Version-Release number of selected component (if applicable):
3.5.4

How reproducible:
100%

Steps to Reproduce:
1. deploy HE
2. start deploying additional host and than select a different interface for the management bridge
3.

Actual results:
It ignores the user specified interface letting host-deploy choose based on the IP address the engine resolved the host FQDN

Expected results:
Two alternatives:
1. it honors the user selection
2. it doesn't ask simply behaving as for regular hosts

Additional info:
Personally I'm for solution number 2.