Minimal implementation of JSON-RPC server

[r4f4ss]

This PR is a minimal implementation of the API-HTTP server, that will provide eth endpoints as specified.

This implementation uses as much as possible functions, routines, and structures from go-ethereum code like node.newHTTPServer, rpcEndpointConfig, etc. This design takes advantage of several verifications and configuration parameters to avoid exploits and attacks already known and solved in go-etherum.

The use of go-ethereum implementations also allows to take advantage of several control features already implemented like rpcprefix, corsdomain, batch-request-limit and etc.

Only a skeleton of the JSON-RPC server and an example API (eth_clientVersion) was implemented, to extend to another APIs using the module eth, one must add to the file <PATH>/shisui/portalnetwork/ethapi/api.go new exportable methods, for instance, the implementation of eth_blockNumber:

func (p *PortalEthereumAPI) BlockNumber() int {
  // TODO - logic here
}

Example of shisui invocation with default HTTP server:

shisui --http

Example of request to the example eth method:

curl 127.0.0.1:8545/ -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_clientVersion","params":[],"id":1}'

Obs: The old method web3_clientVersion was kept in the module web3 and migrated to this new implementation, to avoid any incompatibilities with previous behavior.

Obs2: rpc.port default port was changed to 30304 to avoid conflicts with 8545 used historically by go-ethereum for api-http .

[GrapeBaBa]

@r4f4ss Thank you very much for contribution for shisui. The current Portal API Spec is here, we only implemented discv5 and portal history namespace API right now and we didn't start eth namespace. You are correct that we should resue go-ethereum impl so that we used rpc.server struct and register new portal namespace for exposing the API of shisui. I think the new flags you introduced is good, I will look deeply for that and give feedback. @fearlessfe Please also take a look.

[r4f4ss]

Thank you guys a lot for the feedback!

[r4f4ss]

According to this Portal Network explanation from Ethereum documentation:

The core idea of the Portal Network is to take the best bits of the current networking stack by enabling information needed by light clients, such as historical data and the identity of the current head of the chain to be served through a lightweight DevP2P style peer-to-peer decentralized network using a DHT(opens in a new tab) (similar to Bittorrent).

the design choice of create new servers is wrong. Feedback also showed limitations of this implementation.

While some flags may be a good contribuition, it is needed further study to confirm it is really needed, also to determine the default parameters value like evmtimeout.