Switch digests to use snappy compression

[dgnorton]

Some enterprise users with larger shards were seeing significant increases in CPU usage caused by reading shard digests. Profiling showed most of the time was spent decompressing the digest data. This PR improves performance of the shard digest writer and reader by switching from gzip to snappy compression, which is faster.

Local test with 13.2 GB shard (3.9 M series & 5.2 M time ranges):

gzip:   read in 4.5 seconds (80.7 MB digest)
snappy: read in 2.4 seconds (101.9 MB digest)

[e-dard]

I have a comment and a suggestion:

1. How will this handle existing digests in the wild that are gzipped? What's the upgrade path from an existing gzipped digest to a snappy one?

2. Can you provide a PR description containing the problem, why the PR helps solve it, and any performance data you have, even if it "this is x times faster locally".

[dgnorton]

@e-dard

1. When it attempts to check the digest to see if it’s fresh, it first tries to read the manifest. That read will fail. Any failure while checking if its fresh is treated as stale and the digest is regenerated.

2. Will do

[e-dard]

LGTM 👍