feat(rpc): Add address_ namespace and bindings

[perama-v]

Description

Progress toward:

• Temperature check: support address_getAppearances #4054

Changes

address_ namespace addition including:
- add AddressApi trait in rpc-api
- add to RPC builder
- add placeholder implementation for address_getAppearances

[mattsse]

supportive, since this doesn't add any overhead,

but like to see some serde examples how the request response objects should look like

[onbjerg]

Would want this to be documented fully in the book (e.g. in book/jsonrpc) in the same PR since it isn't a standard namespace

[perama-v]

Would want this to be documented fully in the book (e.g. in book/jsonrpc) in the same PR since it isn't a standard namespace

Docs added and examples included that mirror the spec/spectests

[gakonst]

Just to make this explicit would like to be sensitive with merging this upstream and maintaining the code..so I am happy we're iterating on it and would like to ideally figure out how to run it as a separate binary as well?

[perama-v]

Just to make this explicit would like to be sensitive with merging this upstream and maintaining the code..so I am happy we're iterating on it and would like to ideally figure out how to run it as a separate binary as well?

Thanks, appreciate that.

I consider this family (4054) an exploration of "what could this feature look like, and how could it be implemented?", with the outcome being discovery of whether it is a good feature and what a good implementation could look like.

Happy to explore the design space including specific ideas anyone has.

Could you expand the concept of a separate binary more? On first take it sounds like you are describing the following:

Currently, the Execution stage has inspectors that can gather data. The result of the inspector could be stored directly in to a table alongside other tables in reth, alternatively it could call a separate binary and pass the inspector data over. The separate binary listens for and accepts the data, processes and stores in some representation that reth is unaware of. Then to serve the method reth and the separate binary again call each other (depending on where the call is set up to be served from) and the data aggregated for the response.

[gakonst]

Closing this as stale, we'll re-incorporate these ideas as we venture into custom stages with Reth CLI Extensions and the Declarative Node Builder API that @mattsse is spearheading.