Fixes scionproto#4364

…terfaces() method.

* give the control service a static port.
* use that in the topo config as the hidden_path service address for use by the discovery service.
* This change does not yet include the associated changes to the config generators.

The CS public address and the CS scion address can now be the same, while the service resolver explicitly gets a different port.

I am experimenting with the possibility of configuring the service resolver address as the regular address field of a new service named "service_resolution". (oncilla@ thinks it's a bad idea. I do not understand why yet but I guess I'll find out).

Also updated tests to match the intended changes, and to call assert.Equal() with arguments in the correct order.

If the service resolution address isn't configured, let it have a random port.

The dispatcher dynamically assigns a port and also registers it as the recipient of resolution requests. It appears that no knowledge of the port is required outside of that.

… dynamic port.

Doing this allows the CS's SCION address to have the same host/port as the CS's public address (by default) instead of being dynamic. This in turn makes it discoverable, which allows the hidden path registry to be reachable.

This approach allows the topology file to declare the hidden_path registry address to be obviously identical to the address configured for the CS... much less confusing.

… doesn't need to be configurable.

…ution addr.

… the same address as cs.

…or the hidden segment service. It's not needed. The local optimization has low value and won't be done at this time if ever.

This avoids the need for special behavior to handle nil metadata in a few places.

This method isn't useful anymore. All paths which metadata gets used now have real metadata.

… truly complete and safe to use.