graphql: fee history fields

[s1na]

This PR adds the NextBaseFeePerGas to Block and EffectiveTip to Transaction to make it easier for clients to compute fee history themselves. Note I made the tx reward sorting logic in our fee history algorithm stable so clients can compute consistent results.

Example client script: https://gist.github.com/s1na/851ad57e8fca7c74b2464207b2e99021
Result of a run on a few Goerli blocks:

❯ node index.js 4 6415924 "50, 75"
# JSON-RPC result
{
  oldestBlock: '0x61e631',
  reward: [
    [ '0x9502f900', '0x165a0bbf9' ],
    [ '0x59682f00', '0x59682f00' ],
    [ '0x3b9aca00', '0x9502f900' ],
    [ '0x9502f900', '0x9502f900' ]
  ],
  baseFeePerGas: [ '0x7', '0x7', '0x7', '0x7', '0x7' ],
  gasUsedRatio: [
    0.10796890077097406,
    0.0061631333333333335,
    0.008546466666666667,
    0.13900370378341118
  ]
}
# GraphQL Result
{
  oldestBlock: '0x61e631',
  baseFeePerGas: [ '0x7', '0x7', '0x7', '0x7', '0x7' ],
  gasUsedRatio: [
    0.10796890077097406,
    0.0061631333333333335,
    0.008546466666666667,
    0.13900370378341118
  ],
  rewards: [
    [ '0x9502f900', '0x165a0bbf9' ],
    [ '0x59682f00', '0x59682f00' ],
    [ '0x3b9aca00', '0x9502f900' ],
    [ '0x9502f900', '0x9502f900' ]
  ]
}

Fixes #24386

[s1na]

I applied the review comments and fixed some minor issues. Ready for review

[rjl493456442]

Left a few comments.

[rjl493456442]

for the non-finalized transaction, the t.block can be nil. Please add one more check here.

[s1na]

Ah right. I had copied some stuff from EffectiveGasPrice which has the same issue. Added a check in both methods.

Do you think it makes sense to compute and use the latest block's nextBaseFee for pending txes?

[rjl493456442]

maybe we can simply return an error instead? @fjl @karalabe What do you think?

[holiman]

I think it's safer to return an error rather than 'speculate' on the tip, for pending transactions.

[rjl493456442]

We need to decide what's the semantic of EffectiveGasPrice, EffectiveTip and NextBaseFeePerGas in case the basefee is not existent.

Currently it's returned as 0 in this PR, it's good to me though. Otherwise code is good to me.

[holiman]

in case the basefee is not existent.

in which cases is it not existant? Do you mean blocks prior to the fork?

[s1na]

Do you mean blocks prior to the fork?

Yes that's what Gary is referring to. Right now these fields (EffectiveTip) simply return nil. I was exploring an alternative to returning an error, which is have different Transaction types, each with fields that makes sense for that type

[holiman]

This pr, as is, what happens if you compare json-rpc versus graphql on blocks prior to the fork?

[holiman]

LGTM