chore(net): extract NetworkHandle methods for launching node to traits

[emhane]

Ref #9872

• Adds new traits BlockDownloaderProvider in order to use generic network in node builder, instead of concrete type NetworkHandle
• Add new trait FullNetwork which unifies behaviour needed to launch node
• Adds PeersHandleProvider to integrate generic network in testing
• Moves necessary types from reth-network to reth-network-types in order to extract NetworkHandle methods into new traits

Note: In order to move BlockDownloaderProvider to reth-network-api, the FetchClient type would have to move to reth-network-types, and reth_network_p2p::EthResponseValidator and reth_network_p2p::HeadersRequest would have to move out of reth-network-p2p. The latter, is to remove dep on reth-network-types from reth-network-p2p, since FetchClient depends on reth-network-p2p

[mattsse]

looks like a lot of the changes are unrelated and due to moved use statements, please try to avoid that in a pr that also moves stuff around because this makes it a lot harder to review

I'd like to break this down, can we start this process with a pr that introduces the new traits and perhaps (multiple) prs that move the types to network-types as prep?

[mattsse]

did anything change here?
all of this looks unrelated, hard to tell

[emhane]

hm, sometimes when bases switches, changes on main look like new changes. I checked this out from emhane/network-types originally.

[emhane]

the module preludes I crossed, I cleaned up, is this a problem?

[mattsse]

I would still prefer if we could do this incrementally, because it's a bit to keep an overview about why certain things are moved where.

I still think we can move the types that we need first and then introduce the traits

[mattsse]

hmm, this would be more appropriate in network-api I believe

[emhane]

this is needed in PeersHandle type, so needs to stay too. we should try and keep types in the designated types crate and traits in the designated api crate, just like it's cleanly done for reth-rpc-eth-api and reth-rpc-eth-types

[mattsse]

these are all network api related types so I don't understand why we can't move this to the API crate, types is intended for standalone network related types, types we only used for interacting with network API functions don't fit here like command types

[emhane]

we can re-export them in reth-network-api, but it's much more intentional design if we keep types in types and api in api

[emhane]

I would still prefer if we could do this incrementally, because it's a bit to keep an overview about why certain things are moved where.

I still think we can move the types that we need first and then introduce the traits

I think that argument is contradictory, since the traits and cyclical deps are the reason why the types need to move

[mattsse]

okay convinced but please keep these smaller moving forward