KnownFileList: bound known.met growth with per-hash cap + 30-day TTL - #598

known2_64.met is the AICH (Advanced Intelligent Corruption Handling)
hashset cache: a Merkle tree of SHA-1 hashes per shared file, used
by peers to recover from sub-part-granularity corruption. Each entry
is keyed by its AICH root hash; ngosang's #597 report had it at
1.1 GB. The file has no mtime-touch bloat (entries are
content-addressed, dedup is already in place since #581), but it
never shrinks: once a hashset is cached, the entry stays even after
the underlying file leaves the user's library.

After #598's known.met TTL prune drops ~14 k orphaned live entries
on a long-lived profile, those hashes' AICH entries in
known2_64.met are dead weight and should follow them out.

Add CKnownFileList::CollectLiveAICHRoots() -- walks
m_knownFileMap and m_duplicateFileList under list_mut, returns the
set of AICH master hashes still referenced by either. Both lists
need to be scanned: Append's demote branch parks a record (with its
hashset) on the duplicate list while the new record takes the live
slot, and an mtime-restore can re-promote the duplicate later.
Dropping a duplicate's hashset would silently lose it on re-promote.

Extend CAICHSyncTask::Entry()'s existing known2_64.met walk: open a
"<name>.new" temp file via CFile::write_safe, and for each entry
read from the source, either copy it through to the temp (if its
root hash is in liveRoots) or skip it. On clean walk completion the
Close() atomic-renames .new over the original; on corruption catch
or IO error the temp is removed without finalising, leaving the
source's existing truncation-recovery path intact. Hashset bytes
are streamed through a 64 KB buffer rather than slurped, so a
single large-file entry can't dominate the working set.

The dedup root-hash cache (s_rootHashCache, #581) mirrored the old
file; invalidate it after a non-zero drop so the next SaveHashSet
rebuilds against the rewritten known2_64.met.

Effective TTL is inherited from known.met: a record evicted there
by PruneDuplicates ages out of liveRoots and its hashset gets
dropped on the next AICH sync. Decoupled lifecycles would require
bumping KNOWN2_MET_VERSION to add a per-entry timestamp (the file
format is positional, not tag-based), which is out of scope here.

Defensive: if knownfiles isn't yet populated (empty liveRoots), the
prune is skipped -- we don't wipe everything on a misconfigured
start.

…rop dead VBT path (amule-project#598)

Sizes the ed2k block-transfer pipeline to the bandwidth-delay product
(BDP) in both directions, so throughput holds up on low-latency LAN
links and high-latency internet links alike, and removes the dead VBT
(value-based-type-tags) ed2k-v2 code path.

Download - adaptive request depth. Instead of a fixed 3-deep request
queue, each source's depth is sized to its BDP,
2*(rate*minRTT/EMBLOCKSIZE)+3, clamped to [3,24]. It stays shallow
against a fast LAN peer (avoiding the burst/starve oscillation a deep
queue provokes on a sub-millisecond link) and goes deep against a high-latency WAN peer
(hiding the round-trip). minRTT is measured per source as the minimum
request->first-byte time; the wire still carries the protocol-mandated
3 blocks per OP_REQUESTPARTS. The 24 clamp is deliberate: socket
telemetry showed the WAN ceiling is the OS TCP send-buffer autotune
limit (~4 MB -> ~40 MB/s at 100 ms RTT), which 24 (~4.3 MB in flight)
already covers; 24 also stays within eMule's own pending range (gate
2*blockCount = 18, with a top-up batch reaching ~27).

Upload - adaptive send-ahead depth. Raises the disk I/O thread's
fast-slot send-ahead buffer from 5 to 10 blocks: the upload-side mirror
of the same BDP limit. A shallow buffer drains before the next refill
and caps throughput on a high-RTT link. Cost is a transient ~1.8 MB per
active fast slot, self-bounded by the OS TCP send buffer.

VBT removal. Drops the value-based-type-tags ed2k-v2 path, which never
shipped in a release (nValueBasedTypeTags was hardcoded 0 on send and
GetVBTTags() always returned false), simplifying the block-request and
known-file packet builders.

Benchmarks (macOS leecher <-> bare-metal Linux seeder, dummynet-injected
latency, 120 s steady state, current master vs this PR, both sides
matched per config):

  RTT     Stock (fixed-3 + buf-5)   This PR (cap-24 + buf-10)
  1 ms    131 MB/s                  128 MB/s   (no regression)
  50 ms   5.8 MB/s                  65 MB/s    (~11x)
  100 ms  3.0 MB/s                  35 MB/s    (~12x)

The WAN ceiling is the OS TCP send buffer, not request depth (verified
via ss -tmi); raising net.ipv4.tcp_wmem is host tuning, out of scope.