fuzz: Add upgrade/downgrade simulation to chanmon_consistency and fix chacha20 build

[Atishyy27]

Closes #4452

This PR introduces upgrade/downgrade serialization coverage to the chanmon_consistency fuzzer as discussed.

Changes:

1. Fuzzer Logic: Modified the reload_node closure in chanmon_consistency.rs. Based on a fuzzer input byte, it randomly appends a dummy/unknown odd-type TLV record (0xBADF00D1) to the serialized ChannelManager byte stream before reloading. This simulates loading data written by a newer version, ensuring we don't drop channels on unknown odd TLVs.
2. Build Fix: Added the missing seek_to_block dummy method to the #[cfg(fuzzing)] block of ChaCha20 in lightning/src/crypto/chacha20.rs. Without this, the fuzzer binaries currently fail to compile on main (Exit Code 1).

[ldk-reviews-bot]

👋 I see @joostjager was un-assigned.
If you'd like another reviewer assignment, please click here.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.21%. Comparing base (cb951b4) to head (2358ca7).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4499      +/-   ##
==========================================
+ Coverage   86.18%   86.21%   +0.03%     
==========================================
  Files         160      160              
  Lines      107441   107441              
  Branches   107441   107441              
==========================================
+ Hits        92593    92634      +41     
+ Misses      12229    12189      -40     
+ Partials     2619     2618       -1     

Flag	Coverage Δ
tests	86.21% <ø> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TheBlueMatt]

Huh? In order to do an upgrade/downgrade we'll need to actually depend on a previous version of LDK.

[Atishyy27]

Ah, I see! I was initially aiming for forward-compatibility coverage by simulating unknown odd TLVs.

If the goal is actual cross-version testing, should I add a previous version (e.g., 0.0.124 or similar) as a renamed dev-dependency in fuzz/Cargo.toml to perform real comparisons? I'd appreciate a pointer if there's an existing target using this pattern I should follow.

[TheBlueMatt]

See the upgrade tests in tests. Probably just start with 0.2.

[Atishyy27]

Got it. I checked upgrade_downgrade_tests.rs and see the pattern of importing lightning_0_2 alongside the current crate.

Before I go too deep into the implementation for the fuzzer: since lightning_0_2's traits (like chain::Watch, FeeEstimator, Router, etc.) are entirely distinct from the current lightning crate's traits, doing a full read/reload cycle with the older version inside chanmon_consistency.rs would require duplicating a lot of the fuzzer's test harness structs (e.g., TestChainMonitor, FuzzEstimator, KeyProvider) to implement the 0_2 traits.

Shall I go ahead and duplicate those test harness implementations for the 0.2 dependency, or is there a lighter-weight serialization round-trip pattern you had in mind for the fuzzer?