chore(rpc): expose ethapi in node builder for op customisation

[emhane]

Closes #8781

Exposes customisable types encompassed by node-add ons.

• Adds new AT AddOns: NodeAddOns<N: FullNodeComponents> to Node trait.
• Adds new trait NodeAddOns<N: FullNodeComponents>, that aggregates the customisable types in node add-ons. This is future proof, so we don't have to add a new generic to many types in the node builder, if we make a new add-on type customisable, for example the engine rpc api implementation.
• The ATs on NodeAddOns<N> should have the new trait BuilderProvider<N: FullNodeComponents as trait bound, as is done already for AT EthApi. This way we defer instantiating the builder until the entry point to the specific library for this type, i.e. when we leave reth-node-builder scope into the reth-rpc-builder scope. This saves us a lot of hassle of passing around the specific builder instance in reth-node-builder, which comes with the constraint that the type would need to be Send + Sync + Unpin + Default among others to satisfies the existing reth-node-builder code.
• Adds new extension trait to BuilderProvider<N> trait, EthApiBuilderProvider<N>, which specifies the exact context type that needed to build the EthApi. This requirement is set by reth-rpc-builder and propagates to reth-node-builder.
• Plugs type OpEthApi<Eth> into the node builder.

[mattsse]

I'd like to explore if we can leave the AddOns type entirely up the user and instead have the AddOns type as an available AddOns that can be used in this location

[mattsse]

cool, this gets us one step closer.

I believe there are some things we can simplify but I need to think about UX a bit first.
perhaps it's time to rethink some nodebuilder design approaches

only doc nit otherwise lgtm

[emhane]

ye, the whole node builder design could be simplified. in general I prefer

• specifying the type we are building from the start, so long as we aren't storing the built type as a trait object later - having the builder output type accessible as AT makes life easier! now we specify the literal type NodeAdapter everywhere, which isn't clearly associated to its builder. we don't really care what the builder type is...it is only relevant on bootstrap...but all other types in the program are constrained by its output type, i.e. the built type....
• using all builders as trait objects, these are only called once at start of program, so the extra overhead from dynamic dispatch isn't a problem.
• instantiate the builders as late as possible, using trait like new BuilderProvider<N: FullNodeComponents> trait on AT of the type being built. so reversed to first suggestion, let the output type provide its builder as opposed to the builder specifying its output. this way, we don't have to care about the builder being Send + Sync + Clone + Default, just the built type - which probably has those trait bounds imposed on it by how we use that type during the entire execution of the program anyway, i.e. we need to satisfy those anyway for that type.
• not having NodeComoponents be a strict subset of FullNodeComponents has been painful. it's impossible to reference the transition from a generic NodeComponents to a generic FullNodeComponents type atm. alt, an intermediary trait that specifies the BlockchainTree type could be added for transit between the NodeComponents and FullNodeComponents traits. see (chore(rpc): build rpc as OnComponentsInitializedHook #9243).
• not having all components returned by getters in FullNodeComponents, defined as AT, has made the code less flexible. thinking in particular of Network and Tasks here, which has now had to be hardcoded to NetworkHandle and TaskExecutor in several places. would make way for sense if those types could be referenced via FullNodeComponents, just like Provider or Pool.

rethink

can't open the link!

[mattsse]

can't open the link!

gh added this for some reason lol

all of these points are valid, could you open an issue for this please ?

[emhane]

all of these points are valid, could you open an issue for this please ?

done #9543 !