Reduce Generic Parameter Proliferation with `dyn` Trait Objects

[joostjager]

Core types have excessive generic parameters that harm maintainability:

• ChannelManager - 10 type parameters
• OnionMessenger - 9 type parameters
• PeerManager - 8 type parameters

This makes certain refactors nearly impossible. Adding a new dependency to ChannelManager means threading a new generic through dozens of impl blocks, all their where clauses, and every downstream consumer. The friction discourages improvements that would otherwise be straightforward.

Performance concerns are overstated

The traits behind these parameters do I/O, networking, disk access, and cryptographic operations - all measured in microseconds to milliseconds. A vtable call costs ~1 nanosecond. The overhead is unmeasurable noise.

There are no hot paths here. Lightning nodes are I/O-bound, not CPU-bound. No one has ever profiled LDK and found vtable dispatch as a bottleneck - because it isn't one.

Precedent

DynSigner already exists in the codebase and demonstrates that dynamic dispatch works fine for signing operations - one of the more performance-sensitive areas.

Proposal

Start with ChannelManager and convert object-safe traits to dyn. Candidates:

• BroadcasterInterface
• FeeEstimator
• Logger
• EntropySource

Traits with associated types (Watch, SignerProvider) or generic methods (Router) would need more work to become object-safe.

Expected outcome

Significantly reduce ChannelManager's type parameter count. Make future refactors tractable. No measurable performance change.

(co-authored by Claude)

[joostjager]

To illustrate what it currently takes to add a parameter, see 3ba09e9

[TheBlueMatt]

The other issue with dyn objects is they're also unsized, so there's limitations to where you can pass them around without also Boxing them.

[TheBlueMatt]

Actually, if you want to reduce generics, one thing we probably should have done long ago is drop the Deref indirection and instead impl<T: Deref<Target = Trait>> Trait for T for all our traits. Annoying to update bindings to it, but certainly doable.

[joostjager]

I'd prefer to explore going all the way with Arc<dyn Trait>. In practice, long-lived node components are shared across threads anyway, so Arc is the natural choice? If the Deref flexibility only benefits tests or theoretical use cases, it's not worth the readability and maintainability cost.

[TheBlueMatt]

Arc adds Send+Sync requirements that we can't make universal, sadly, I think.

[TheBlueMatt]

Oh, actually it doesn't require Send+Sync, only optionally implements it. I still don't think it works for this use-case though - we'd have to pick either Arc<dyn Trait + Send + Sync> or Arc<dyn Trait> and then everyone would be forced into one or the other. I suppose we could use Arc<dyn Trait + MaybeSend + MaybeSync> to use our existing std feature gating, but I'm not really a fan of leaning more on the std feature gating cause that implies a rather substantial API change based on a feature flag, which is a big no-no.