Switches from pcap_next() to pcap_next_ex() to better handle all error
conditions. This allows, for example, to have a non-zero exit code for
a Zeek process that fails to fully process all packets in a pcap file.
The pcap file format has a global header and a header per packet. The
global header of the pcap in question had a snaplen of 1, but with
packet headers indicating the full number of bytes saved within the
file. It seems like the pcap file must of been artifically edited in
order for it to be this way.
When reporting the captured length of a packet, Apple's version of
libpcap now seems to report the full number of bytes saved within the
pcap's per-packet headers, but other versions seem to report the snaplen
from the global pcap header. This caused the core.truncation test to
behave differently on macOS from other platforms.
I've manually hexedit'd the pcap so that the snaplen is still 1, but
contains just a single packet with a pcap header indicating a length of
8, which is less than the size of the link layer header and so should
still test the original code path that the unit test intended to
exercise.
