Multiple listener support

[dotnwat]

Community feedback in #98 highlighted a lack of multi-network configuration in redpanda in which we don't support listening on multiple networks (#186). For example, the kafka API may serve internal clients on a private network as well as external clients on a publicly routable network.

It appears that the solution is more involved than simply setting up multiple listeners, as the view of advertised broker addresses is dependent on the network a client is on. The example in #98 does a good job of illustrating the issue:

KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:29092,OUTSIDE://0.0.0.0:9092
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka-broker:29092,OUTSIDE://localhost:9092

In this configuration a broker running in a docker container will listen on two ports (29092 and 9092). A separate client (in this case the schema registry) will connect over a private docker network on port 29092 and be told about brokers via the metadata API in a way that makes sense for that network. In this case, it will be told about the advertised listener kafka-broker:29092. However, port 9092 is exposed to the host and when serving metadata requests on that network, it will advertise the same broker but with the address localhost:9092 which is how the host should connect: through the forwarded port.

Implementation in redpanda

The current major issue here seems to be related to our internal metadata model of a broker containing a single endpoint configuration. Effectively we need to carry all end point configurations because brokers must be able to filter advertised addresses based on the network the client is connecting from.

Unresolved issues that would result from a solution that involved updating model::broker:

• Wire protocol changes
• Controller storage format changes

[dotnwat]

This was addressed in #451