FM-99: Ethereum API facade entry

[aakoshh]

Part of consensus-shipyard/ipc#342

Establishes a fendermint_eth_api library crate which can listen to the JSON-RPC and eventually WebSocket requests from Ethereum tools. This is started as another command under fendermint_app:

❯ cargo run -p fendermint_app --release -q -- eth run --help
Run the Ethereum JSON-RPC facade

Usage: fendermint eth run [OPTIONS]

Options:
  -u, --url <URL>              The URL of the Tendermint node's RPC endpoint [env: TENDERMINT_RPC_URL=] [default: http://127.0.0.1:26657]
      --proxy-url <PROXY_URL>  An optional HTTP/S proxy through which to submit requests to the Tendermint node's RPC endpoint
  -h, --help                   Print help

Further to these options, we have some extra settings in default.toml:

# Ethereum API facade.
[eth]

# Ethereum API facade for JSON-RPC.
[eth.http]
# Only accept local connections by default.
host = "127.0.0.1"
# The default port where the Ethereum JSON-RPC API will listen to connections.
port = 8545

# Ethereum API facade for WebSockets.
[eth.ws]
# Only accept local connections by default.
host = "127.0.0.1"
# The default port where the Ethereum WebSocket API will listen to connections.
port = 8546

The default values for the ports have been chosen to match geth.

Why not a separate binary?

Initially I created the fendermint_eth_api as a binary crate with a main.rs, which is where I thought it will have only one job to do, which is to run the server. It would have still required its own settings file, though, so I thought we can move some config utilities to a common crate, like log levels, home directory and tilde handling.

But then I thought it might get confusing how to handle the ~/.fendermint/config directory, which currently has a default.toml. Do we really want operators to have to worry about two different config files?

By putting the entry under the same fendermint application as a subcommand, we don't have to create another Dockerfile, it all gets compiled into one, and just started with a different command and the relevant environment variable overrides. Notably it would not touch the DB section of the settings, and not share a volume with the ABCI container.

Why these JSON-RPC libraries?

I saw the ipc-agent implemented one from scratch, but it can't be separately imported. The jsonrpsee library seems to be most used, but it contains many more features to learn, while the jsonrpc-v2 used by Forest seems simple, and they already worked out the details of making it work with axum, which looked all right in this comparison. I didn't ask if they would make the same choice again, but it looks like an easy start.