Add show servers to query language

[corylanou]

Currently lists only data nodes, with the id/url:

> SHOW SERVERS
name    tags    id      url
----    ----    --      ---
                1       http://Corys-MacBook-Pro.local:8086

Questions:

1. Should this include brokers as well?
2. Original issue stated wanting to show IP and hostname. If we want that, we'll have to change the way we start up the servers to capture IP address when starting.
3. We don't currently store any heartbeat information on data nodes
4. Do we want to return the current index of each data node?
5. Do we want to support any where clauses to show server?
6. Should it be SHOW DATANODES and SHOW BROKERS vs. SHOW SERVERS?

Addresses #1469

[pauldix]

1. Should this include brokers as well?

Yes, it should actually have an extra column that is something like "role" which has data, broker, or both

2. Original issue stated wanting to show IP and hostname. If we want that, we'll have to change the way we start up the servers to capture IP address when starting.

I guess it should just have whatever the connect URL is.

3. We don't currently store any heartbeat information on data nodes

We should keep an in memory map of all heartbeat information. All brokers and data nodes should be heartbeating through raft on a regular basis. The data node heartbeats should include which shards they have and what the last written raft index is for each of those shards.

4. Do we want to return the current index of each data node?

The index only has meaning on a per topic basis. I think we may want to expand this functionality to show the detailed information of each data node, which would include what topics it has, what raft index each one is at, and what it knows about the cluster (other data nodes, brokers, etc)

5. Do we want to support any where clauses to show server?

No, just maybe a SHOW SERVER <id>

6. Should it be SHOW DATANODES and SHOW BROKERS vs. SHOW SERVERS?

I think SHOW SERVERS is probably good.

[otoolep]

I think SHOW SERVERS output should just be limited to the giving back the ID, host, etc i.e. the identifier of each server in the cluster. This seems to make most sense when we're also going to implement SHOW STATS [ON <server>] and possibly something like SHOW DIAGS [ON <server>]. Whatever server identifies are returned by SHOW SERVERS are then fed into the other commands.

If this is not the case, we need clearer requirements for each of there commands, since there is overlap in how they are currently spec'ed out. See: #1470

[otoolep]

@corylanou -- happy to work together on this, so we can come up with something consistent and comprehensive.

[corylanou]

@otoolep I agree, if we are doing show stats, then this should be a more simplistic response that gets you into a more in depth response.

Does it make sense to merge this as is and let you pick it up on your branch with a rebase? Seems like the two issues are pretty closely related.

[otoolep]

Thanks @corylanou -- if you merge, I can develop further. +1 from me once the changelog is updated.