Add support for receiving SNMP traps through a multiplexer

[lunkwill42]

Rationale

As mentioned in Håvard Eidnes' comments in #173, there is often a limit to how many trap receivers that can be meaningfully configured in any one router.

For this reason (and other reasons), the legacy Zino does not actually provide its own SNMP trap listener, but instead connects to an SNMP trap multiplexer service (straps, or nmtrapd in later incarnations, a part of the Scotty framework, I think). The trap multiplexer receives the actual trap messages, and multiplexes them to a UNIX socket that multiple processes can read from. Under this model, Zino never has to be started as a privileged user, only the trap multiplexer does.

This model is not currently supported by Zino 2. It provides its own trap listener, as we wanted it to be as standalone as possible, without introducing dependencies to the older Tcl-based tools.

However, Zino 2 could be extended to also support some kind of trap multiplexer, whether it be straps/nmtrapd or something else.

Some implementation considerations

• A trap multiplexer like nmtrapd will add an extra header to an SNMP trap message before passing it on to a UNIX socket. This header typically contains information about the originators IP address and the length of the incoming packet.
• Zino would have to connect to the UNIX socket and get its trap packets from there. We would have to find some way to feed a raw SNMP trap packet into the PySNMP framework, rather than having PySNMP read it from "the wire" itself.
• Zino 1 features a "watchdog" service: Since the connection to the UNIX socket could be lost without warning, the watchdog takes to automatically re-connect to the UNIX socket if a trap has not been received in some specified interval of time.