eth/gasprice: implement feeHistory API

[zsfelfoldi]

This PR implements the feeHistory EIP-1559 gas price API specified here:
ethereum/execution-specs#212
Original proposal:
https://gist.github.com/zsfelfoldi/473e29106d38525de6b4413e2ebcddf1

[rjl493456442]

We can simplify the thing like this

func (f *Oracle) resolveLastBlockNumber(last rpc.BlockNumber) (*types.Block, uint64, bool, error) {
	var (
		pending *types.Block
		noHead  bool
	)
	if last == rpc.PendingBlockNumber {
		pending, _ = f.backend.BlockByNumber(ctx, last)
		if pending != nil {
			return pending, pending.NumberU64(), false, nil
		}
		last, noHead = rpc.LatestBlockNumber, true
	}
	if last == rpc.LatestBlockNumber {
		latestHeader, err := f.backend.HeaderByNumber(ctx, rpc.LatestBlockNumber)
		if err == nil {
			last = rpc.BlockNumber(latestHeader.Number.Uint64())
			return nil, last, noHead, nil
		} 
		return nil, 0, false, err
	}
	return nil, last, false, nil
}

The headBlockNumber actually is unnecessary. If pending is not nil and it's requested for processing later, we can use the pending field here for checking, instead of using headBlockNumber

And also the latestHeader is also kind of unnecessary since retrieve the header again is cheap because of the cache.

[rjl493456442]

And we can call this function like this. It's much cleaner.

pending, last, noHead, err := f.resolveLastBlockNumber(lastBlockNumber)
	if err != nil {
		return 0, nil, nil, nil, err
	}
	if noHead {
		blockCount--
		if blockCount == 0 {
			return
		}
	}

[zsfelfoldi]

Actually I do need headBlockNumber to enforce maxHistory and avoid requesting future blocks. But factoring out the block number resolving logic is a great idea, I think it's a lot more readable now. Also you're right about latestHeader, saving it is not really imporant and not doing so makes the code simpler.

[rjl493456442]

The headBlockNumber is last returned by resolveLastBlockNumber

[zsfelfoldi]

That's not true if lastBlockNumber was an explicit block number different from the head. We still need the head though to apply maxHistory restriction and prevent future block requests. So I think it's better to also integrate these checks into resolveBlockRange that can also limit blockCount if necessary.

[rjl493456442]

Shouldn't we reject this request in the first place? I don't think request the transaction fees of the future blocks make any sense.

[zsfelfoldi]

Right, it's probably better to reject it explicitly. Now I return an error in this case.

[rjl493456442]

Why not use the hexutil.Big?

[zsfelfoldi]

I wanted to but then forgot about it. Did it now.

[rjl493456442]

I would prefer to return directly if the block count is 0 here. It's cleaner