fix(op): ensure EthApiServer helper trait method default impls, call OpEthApi overrides

[emhane]

Closes #9868

• Replaces inner type on OpEthApi with EthApiInner. This ensure that the default trait method impls kept by OpEthApi, will actually invoke the OpEthApi overrides of other trait methods.
• Inlines getters in EthApiServer helper trait impls for OpEthApi
• Adds getter trait methods for EthState and EthApiSpec, and moves impl of trait methods for EthApi, into default impl, to simplify impl for re-worked OpEthApi type

[mattsse]

This ensure that the default trait method impls kept by OpEthApi, will actually invoke the OpEthApi overrides of other trait methods.

can you please elaborate on this, not obvious to me what this pr fixes.

Adds getter trait methods for EthState and EthApiSpec, and moves impl of trait methods for EthApi, into default impl, to simplify impl for re-worked OpEthApi type

isn't the approach then implement everything that's required on opapi directly and not move more stuff to default impls or did I misunderstood this?

[emhane]

hope this is helpful to understand @mattsse https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f22868e00a2b877425802be4fbbf2f65

[mattsse]

gotcha, where do we have this problem rn?

this sounds more like a general design problem due to the many helper traits with default impls

[mattsse]

okay, now that I had some time to think about this, this makes perfect sense and we need to wrap the inner type as you highlighted

only have naming suggestion

[mattsse]

now your pr about the AT network type makes perfect sense to me,

perhaps we start by removing the taskexecutor generic and replace with Box<dyn>? don't think the generic is actually useful

[emhane]

actually, I'd like to replace both consensus trait object and task executor trait object with generics eventually. trait objects are great for things that aren't in scope for the whole program, but for consensus and task executor that isn't the case and we can make the smol perf gain by resolving them at compile time. also because we already have a great way to pass the components down to the FullNode type, which is via the FullNodeComponents trait.

made an issue #9872, will tackle it before continuing with #9774