Fix reported progress around compaction / defrag

[simolus3]

In some cases, it was possible for reported download progress to go out of the normal range of 0..1, e.g.:

1. Start with empty db, create 100k rows, let client sync and stop at around 50k.
2. Disconnect client, delete 90k rows, re-deploy sync rules.
3. Reconnect client.
4. Observe that it claims to have downloaded 50k rows out of 10k total.

This is because the sync progress heuristic assumes that buckets won't shrink in size. In this PR, we try to detect a bucket being reduced so much that we'd be over 100% when the sync has just started. In this case, we throw local progress away and start from 0. There are still some issues associated with progress around defrags (e.g. since checksums changed, we're downloading everything twice and will have progress go from 0 to 1 twice), but this fixes the most egregious mismatch.

[rkistner]

@simolus3 Could we also explicitly reset the bucket progress when we get a checksum failure? Or more specifically, whenever we hit the deleteBucket logic, the progress for that bucket should be cleared

[simolus3]

Or more specifically, whenever we hit the deleteBucket logic, the progress for that bucket should be cleared

This should already be the case. Our recovery from checksum failures is to restart the connection, which means that we get a new checkpoint and call getBucketOperationProgress() which selects the current counters from ps_buckets. So if the bucket is deleted we'd restart at zero. The internal progress we keep in memory is always just "state from ps_buckets at last checkpoint message + progress inferred from data lines since then".