Topk pr117 rebuild

[zackcam]

This is a rebuild of: #117 with different changes. Thank you detemmienation for setting this up!

What this does

This change vendors the heavykeeper crate into the repo as a local path dependency and tunes it for Valkey. Before this, the module pulled heavykeeper from an external git branch. Vendoring it lets us make TopK-specific memory and correctness changes without waiting on the upstream crate.

Main changes

Vendoring and build:

• Add heavykeeper under heavykeeper/ and switch Cargo.toml to a local path dependency.
• Strip upstream dev-only files from the vendored copy.
• Track our changes to the crate in MODIFICATIONS.md.

Memory reductions (the TopK sketch uses CuckooTopK):

• Use u32 fingerprint and counter cells instead of u64, halving per-cell memory. A u32 counter cannot overflow because counts are saturated on the way in.
• Store item keys up to 15 bytes inline (SmallKey) instead of always heap-allocating. Small keys (IPs, ids, short strings) now cost zero extra bytes.
• Move TopKQueue to single-copy storage and merge the sketch cell arrays, removing duplicated per-key data.
• Remove the decay-threshold lookup table.

Correctness and upkeep:

• Rebuild the priority-queue lookup table when hashbrown tombstones grow it, so a key's memory footprint stays fixed under churn.
• Add generic Fingerprint/Counter types so the cell width is a type parameter.
• Add defrag support for the crate's large heap allocations.
• Rebase on merged upstream commits and update the memory accounting to charge only spilled (heap) key bytes; inline keys are already counted in the queue's structural size.
• The module code shrinks too: TopKObject no longer stores k/width/depth/decay separately, since those are read from the sketch.

Tests

• All heavykeeper crate tests pass (161).
• Module TopK integration tests pass (correctness, DUMP/RESTORE round-trip, memory-gauge stress, count saturation).
• Full module builds clean.

Performance and memory

K	sketch	Redis + items	VB bytes	VB vs Redis
10	8x7	2960	1216	-59%
50	8x7	4560	2896	-36%

K	sketch	Redis + items	VB bytes	VB vs Redis
100	16x7	7008	5528	-21%
100	64x7	9696	8600	-11%
100	256x7	20448	20888	+2%

two example tables, at large large k and sketches, we cap at 15% for more memory (Note this is using the items added for redis memory which is untracked by memory usage in redis but is a part of the topk object)

Notes

The vendored crate keeps upstream's other implementations (TopK, BucketedTopK) even though the module only uses CuckooTopK, to stay a faithful mirror of the upstream crate.

For the future we will try and get these changes accepted upstream but if unable we will continue to use the vendored crate