Make partition deletion resilient against oversize

[tobim]

We now reingest data from oversized partitions on startup.

📝 Checklist

• All user-facing changes have changelog entries.
• The changes are reflected on vast.io, if necessary.
• The PR description contains instructions for the reviewer, if necessary.

🎯 Review Instructions

Testing instructions: You can increase the size of a partition files manually beyond the fbs size limit, then start VAST:

vast -N import zeek < libvast_test/artifacts/logs/zeek/conn.log
dd if=/dev/zero bs=1G seek=3 count=0 of=vast.db/index/<the_uuid>
vast start &
vast flush

After that sequence the database should be fully repaired.

[tobim]

This still needs a fix for the index statistics.

[lava]

Looks good to me from a high-level perspective: When we attempt to erase partitions that are corrupted we try to guess the store file and erase that; and when we attempt to start VAST and encounter an oversized partition we try to fix the DB state by reimporting the data.

It should actually be possible to create an unit test for this by creating a regular partition, adjusting the seek position to >= 2G, and verifying that the data is queryable after the index has restarted.