Don't limit the snaplen by default

[tsg]

This is triggered by #145, where our default value for snaplen was too small for a virtual interface (docker0).

We could "fix" it by adding docker to the list of virtual interfaces we detect by name, but it seems to me that a better approach would be to read the MTU size of the interface and set the default snaplen based on that.

[tsg]

Seems that we cannot rely on the MTU value. Virtual interfaces seem to send arbitrary sized packets, the only limit seems to be 64K. We should still be able to find a reliable way of knowing if an interval is virtual or not.

[tsg]

The two possible solutions I see:

• simply leave the default to 65535, which is enough in all cases that I've seen and also confirmed by the libpcap man page to be safe for all networks.
• Do adaptive snaplen: whenever the socket reports that it has seen a packet larger than the current snaplen, double the snaplen.

The second solution makes for an optimized snaplen, but it's clearly more complex and has the disadvantage that we still lose data on each first "bigger" packet. It's also impossible to predict when the loss will happen. It's also not clear right now if changing the snaplen on existing socket can cause any drops during the change.

The good news about the first option is that libpcap doesn't seem to be affected by the snaplen change if the packets are small (~1500 bytes), so when using the pcap sniffer there isn't really a downside to just using 65535.

For the af_packet sniffer type, a larger "frame" size means fewer slots in memory map. So on the same memory consumption, we're more likely to drop packets, but the CPU time consumed also doesn't seem to vary if the the packets are small.

Given the above, I tend to favor the first solution.