match: Fix hash_search() duplicate-chain regression (#1115) and collision flood

[seks99x]

Summary

This PR resolves the sparse-file performance regression reported in #1115 (introduced by the MAX_CHAIN_LEN cap for #217) and bounds the CPU work spent in hash_search() when rolling across regions with repeated weak-checksum collisions.

Root Cause

1. Duplicate entries in a hash chain exhausting MAX_CHAIN_LEN (rsync 3.5.0 is very slow and uses a lot of CPU compared to 3.4.x with large sparse files #1115):
   When transferring large sparse or disk image files (where the block size reaches 64 KiB or 128 KiB), long runs of identical blocks (such as 0x00 sparse holes) land on the same hash chain as other constant-byte blocks (such as 0xFF) due to get_checksum1() arithmetic modulo 65536. Because build_hash_table() inserts blocks in sequential order, thousands of identical 0x00 blocks sit at the front of the chain. When hash_search() looks for a block sitting behind them, it walks and memcmps every identical 0x00 entry until hitting MAX_CHAIN_LEN (1024), aborting before it can reach valid matching blocks further down the chain.

2. Per-byte strong-checksum evaluation on unmatched collision runs:
   When a chain fails to produce a strong-checksum match (either after exhausting MAX_CHAIN_LEN or after computing get_checksum2()), hash_search() falls back to rolling forward 1 byte at a time. Across a constant-byte or colliding region that does not exist in the basis file, this forces a full get_checksum2() calculation at every single byte offset.

Changes

• Unlink duplicate false-alarm nodes (last_false_sum2):
  When a chain entry fails the strong-checksum comparison, record its sum2 pointer in last_false_sum2. Subsequent entries in the same chain that share the exact same sum1, len, and sum2 (and do not carry SUMFLG_SAME_OFFSET in --inplace mode) are unlinked from the chain (*prev = s->sums[i].chain) without incrementing chain_len. One representative of that block remains in the chain for future matches (with want_i / aligned_i continuing to resolve sequential indices directly from s->sums[]), while eliminating redundant memcmp calls and allowing hash_search() to reach valid blocks behind long duplicate runs.
• Skip block window after 4 consecutive false-alarm offsets (consecutive_false_offsets):
  If 4 consecutive 1-byte rolling offsets hit a weak-checksum collision (done_csum2 or chain_len > MAX_CHAIN_LEN) without matching any block in the chain, advance offset by a full block window (k - 1 prior to the loop's ++offset) rather than computing a strong checksum on every byte.
• Regression test (testsuite/collision_test.py):
  Verifies both duplicate-chain unlinking (rsync 3.5.0 is very slow and uses a lot of CPU compared to 3.4.x with large sparse files #1115) and bounded hash_hits on consecutive unmatched weak-checksum collisions.

Note on Even Block Sizes and Repeated Sequences

Because get_checksum1() accumulates s1 and s2 modulo $65536$, large power-of-2 / even block sizes (such as 65536 and 131072) can cause distinct constant-byte sequences to share the same 32-bit weak checksum. When rolling across unmatched repeated-byte sequences under an even block size, repeated weak collisions will trigger the consecutive-collision skip and transfer the colliding window as literal data. Users transferring files dominated by distinct constant-byte runs who want to avoid weak-checksum collisions altogether can specify an odd --block-size (e.g., --block-size=131071), which is coprime to $65536$ and gives all 256 constant-byte fills distinct weak checksums.

Many thanks to @samueloph and @dfskoll for reporting the MAX_CHAIN_LEN regression.

[steadytao]

Four misses do not prove that the next offsets cannot match. This skips valid basis matches and can substantially increase literal data. Split out the #1115 chain correction; any collision-flood policy needs explicit CPU and bandwidth bounds plus regressions with valid matches at each skip boundary. Also cover --inplace same-offset preservation when mutating the chain.