Add proper support for eth_hashrate

[timbeiko]

We should properly support eth_hashrate, as it currently always returns 0.

We need to add eth_submitHashrate that is just a two arg function, a BigInteger first arg (value) and a hash as second arg (key) and we put it in a hashmap. Then for eth_hashrate we sum up the values of the map with the cpu rate.

We may want to size limit the hashmap (where we evict the least recently updated value) and remove zero rates to prevent memory bloat attacks.

[RatanRSur]

If we always return 0, does this count as a bug?

[matkt]

If we always return 0, does this count as a bug?

I would say it’s an improvement rather than a bug

[matkt]

Implementation

• Implemented submitHashrate endpoint which is by default limited to 1000 sealers. Adding a 1001 will remove the oldest from the list (0x0 hashrate is refused)
• Updated eth_hashrateendpoint so that it returns the cumulative hashrate of all sealers if the list is not empty. Otherwise it returns the local hashrate
• Added hashrate submission with Stratum1EthProxyProtocol and Stratum1Protocol
• Added CLI Option to modify the number of sealers limit

Test

• Tested the hashrate submission with stratum
• Tested the hashrate submission with json rpc api

{"id":1,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x00","0x01"]}

{"id":1,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x01","0x01"]}

• Tested with CPU and GPU mining

See this PR : #1063