Use a common signals handler

[inercia]

Both the router and the DNS server use a similar signals handler, so this PR implements a common handler for them. The DNS server and the router implement methods like Stop() and Status() now, called from the handler when some specific signals are received...

[rade]

Erhm. The signal handler kept the router main() alive. It's now in a goroutine, so doesn't. Hence weave dies on startup.

[rade]

I see that in the nameserver code, DNSServer.Start() blocks. And there is a whole bunch of logic to accomplish that. A Start() method shouldn't block. And I see no compelling reason why you'd want dns server startup to block. other than to keep the main loop alive. the signal handler loop is a fine choice for the latter, imo.

[inercia]

@rade I have thought several times about renaming the Start()/Stop() methods in the DNSServer to ListenAndServe()/Shutdown(). Those names would describe much better what they do, and it would follow the same convention found in other places in the standard library... ListenAndServe() is usually a blocking method, the last method call in a main()function and, IMHO, much better than a signals handler...

If you agree, I will make StartSignalHandlers() a blocking function (so the router does not need to be changed) and I will leave the Start()/Stop()->ListenAndServe()/Shutdown() for a future PR...

[rade]

ok, but then it can't be called *Start*SignalHandlers. SignalHandlerLoop?