Determine correct behavior of eth_getBlockByNumber, latest

[RatanRSur]

Currently, we return the latest chain head even if we don't have state for it. For example, in fast sync. At least one other client seems to return the latest head that we have the state for, which means while fast syncing they return 0. We should work out what the behavior should be.

This has implications for how hive testing is currently done.

[jflo]

After reviewing the json-rpc spec, I think the spirit of the design implies 'latest' to mean the last complete block. In no particular order:

1. Latest refers to last mined block. That implies all state is established for that block.
2. eth_getBlockByNumber is documented as returning the same value as eth_getBlockByHash would, which includes state, logs, txReceipts etc.
3. It may be more intuitive for Latest to return head of the fully synced chain, and allow Pending to include the latest available (yet incomplete) block.

The other argument I considered was that maybe this method shouldn't use default block parameters at all. eth_getBlockByNumber is considered a "history" method. The spec implies that default block parameters are intended for use:

"When requests are made that act on the state of Ethereum, the last default block parameter determines the height of the block."

So what does it mean to use a history method to get the most recent entry into a ledger, when that entry may be incomplete?

[jflo]

Nethermind and Geth both use option 1. We should do that too.