pcap index: Compress offsets that exceed threshold

[mattnibs]

Introduce ranger.Envelope.Merge that merges two Envelopes into a
single Envelope.

This fixes bug where indexing a large pcap causes the system to
oom panic.

When constructing the time index for a pcap, compress the array of
offset points to an Envelope when the size of the array reaches a
certain threshold. Subsequent compressions will be merged into the
section's Envelope keeping the memory footprint low.

The downside to this approach is for the indexes of large pcap files
the difference between adjacent X values starts out very wide then
narrows as one iterate through the Bins. This will result in larger
pcap scans (i.e. slow searches) for hits at the beginning of the file
and smaller scans (i.e. faster searches) towards the end. Consensus
was that the difference in search times probably won't be noticeable
enough to warrant introducing a fancier algorithm. Filed brimdata/brimcap#269 to
revisit.

Closes #1039

[mattnibs]

Some stats for this:

branch: master (33GB pcap file)
$ gtime -p pcap index -r ~/brimdata/wrccdc18/pcaps/all.pcap > /dev/null
real 30.46
user 17.17
sys 16.54

branch: pcap-index-oom (33GB pcap file)
$ gtime -p pcap index -r ~/brimdata/wrccdc18/pcaps/all.pcap > /dev/null
real 20.13
user 9.73
sys 9.30

[philrz]

I tested this out using Brim commit 13cac48 pointing at zqd commit 3623895 (this branch) and found I was able to successfully import the 35 GB pcap on the same 4 GB VM where I'd witnessed the OOM in the original repro in #1039. I watched the RES memory used by zqd and saw a similar low ceiling as @mattnibs showed in his chart above. 👍

[mccanne]

This looks good. As we discussed, we can make the algorithm better down the road if/when warranted.