seg compress: fix LCP initialization

[battlmonstr]

lcp[inv[n-1]] was not initialized.
Its value was reused from a previously processed unrelated superstring. This made the seg file dependant on the order in which parallel workers process superstrings.

Effects of the fix:

• the torrent hashes for large files will change from the previous version
• a bit more stable torrent hash with parallel mode generation
• easier to implement in silkworm (without this fix, we'll have to introduce the same bug in silkworm to produce identical files)

[battlmonstr]

@AskAlexSharov is it required to bump snapshot file versions for such a change?

[battlmonstr]

Debugging details:

with v1-003500-004000-transactions.seg

the score of a few patterns was different, because processSuperstring was producing less patterns for some words,
compared to the case where lcp[] buffer was zero-initialized:

silkworm
score pattern_hex
10367780 ffffffffffffffffffffffffffffffffffffffff
83072 ffffffffffffffffffffffffffffffffffffffff16ff5b505b50565b6000610ba9336109a5565b15610f0557610bb7846116d7565b15610ca0577f92ca3a8085

erigon
score pattern_hex
506200 ffffffffffffffffffffffffffffffffffffffff
80960 ffffffffffffffffffffffffffffffffffffffff16ff5b505b50565b6000610ba9336109a5565b15610f0557610bb7846116d7565b15610ca0577f92ca3a8085

This led to a different pattern selection by optimiseCluster for some words, and then a different pattern usage frequency and a different huffman coding table.

The compression ratio is almost not affected by this change:

• before the fix: 1880400486 bytes
• after the fix: 1880397769 bytes

[AskAlexSharov]

@mholt-dv , do you wanna include this fix to v2 files? like erigon decompress | erigon compress ?

FYI: i don't mind to merge algo change which will change compression logic.

[AskAlexSharov]

also tested: no ratio affect, "erigon snapshots diff" says that files are identical. let's merge.