perf: generic LRU cache with struct key for prepared statement cache

[mykaul]

Summary

• Make internal/lru.Cache generic (Cache[K comparable]) to support typed keys
• Replace the prepared statement cache's string-concatenation key with a stmtCacheKey struct, eliminating per-query allocation from fmt.Sprintf and fixing a theoretical key collision when host IDs or keyspace names contain the separator character
• Update routingKeyInfoLRU to use the typed Cache[string]

Extracted from #779.

Benchmark results

Before (string-concatenation key) vs after (struct key) — 5 runs, Intel i7-1270P.

Lookup (hot path — cache hit)

	ns/op	B/op	allocs/op
Before (StringKeyLookup)	13.7 ±3%	0	0
After (StructKeyLookup)	17.1 ±3%	0	0
Delta	+25%	—	—

Struct key lookup is ~3ns slower due to comparing 3 fields vs one pre-built string. Both are zero-allocation. This is the steady-state path for repeated queries — the regression is negligible in absolute terms (~3ns).

Insert (cold path — cache miss, key construction + insertion)

	ns/op	B/op	allocs/op
Before (StringKeyInsert)	315.6 ±2%	248	6
After (StructKeyInsert)	214.6 ±2%	168	4
Delta	-32%	-32%	-33%

This is the path that matters for new queries: every new (host, keyspace, statement) tuple hits this on first use. The old approach allocated a concatenated string via fmt.Sprintf on every call. The struct key references the original strings without copying.

Net effect

The insert path (where the allocation overhead lived) improves by 32% across the board. The lookup regression of ~3ns is dwarfed by the real-world query execution time. Additionally, the struct key fixes a correctness issue: the old concatenation hostID + keyspace + statement could collide when field boundaries overlap (e.g., hostID="ab", keyspace="cd" vs hostID="a", keyspace="bcd").

Signed-off-by: Yaniv Kaul yaniv.kaul@scylladb.com

[mykaul]

CI failure seems to be #822 again.