Support more exit nodes

[eenblam]

Right now, we have a list of whitelisted exit node IPs, but the monitor only thinks about the latest update it received. We can refactor to account for multiple exit nodes in how we relay results.

[eenblam]

@bennlich @jhpoelen thoughts on this? I implemented a simple version that just adds up the number of routes and gateways for each exit node, but that doesn't really make sense and is misleading.

I am keying on alive-${ip}, so we can just look at each one individually. If that sounds like a good start, I can hammer it out.

[bennlich]

Yeah--I think a good place to start would be to show one table per exit node. I think the summary at the top can be thought of as a table summary (it essentially counts the rows in the table). (Related: we don't really want/need a separate POST route for the summary info--with a dump of an exit node's routing table, the monitor has everything it needs to render a summary).

After we have a table/summary per exit node, we could put a big mesh overview summary of tables on top of that. Maybe something like, # of live exit nodes, # of independent meshes, # of unique gateway IPs, # of unique mesh IPs.