eth RPC should use Engine's extra_info() to populate header fields

[stevenroose]

As pointed out in ethereum/go-ethereum#3230, the Golang RPC client expects a mixHash field in the result of the eth_getBlockByNumber method.

Parity, also when using --geth, provides this information in sealFields instead of in mixHash.

---

The eth RPC should remain consensus-system neutral, however Engine trait provides extra_info() function which can provide these fields (for Ethash engine, it translates a header into these extra fields mixHash and nonce). BlockChainClient trait will need an additional function which proxys the Engine::extra_info() function through to Eth RPC handler so it can return it under the normal circumstances of returning a header.

The real difficult part is getting this into the JSONRPC serialiser, which afaik is hard coded to use only a structs fields. A custom serialiser will likely have to be done with the serialisable struct having an additional extra_info field, which is not serialised directly, but rather provides these additional key/value pairs for the JSON object.

[fjl]

We also expect "v", "r", "s" for transactions, "root" and "logsBloom" for receipts btw. All of these are needed so we can reconstruct the consensus-related objects from RPC return values. I wanted to write an ERC proposal about this but didn't get to it yet.

[gavofyork]

@fjl best to place that in a separate issue.

[fjl]

Transactions: #3158
Receipts: #3159

[tomusdrw]

Closed via #3169

[stevenroose]

It seems that I'm again missing the mixHash field..