Add effectiveGasPrice to eth_getTransactionReceipt

[lightclient]

After some discussions, it appears most prefer to add effectiveGasPrice to the receipt object because it is a computed value, like gasUsed. I've written the method with the idea that legacy transactions will simply return tx.gas_price for the effectiveGasPrice and EIP-1559 txs will actually compute the correct value. This should avoid a scenario where RPC consumers need to branch depending on the tx type to determine the effective cost.

cc: @MicahZoltu @tkstanczak @timbeiko @GregTheGreek @fvictorio

[lightclient]

@timbeiko seems like there hasn't been any push back on this. Do you want to go ahead and merge or should we bring it up briefly in ACD?

EDIT: sorry, we should probably discuss on ACD briefly. I see geth uses the effectiveGasPrice as the gasPrice for mined txs.

[lightclient]

Per ACD, we'll no longer return effectiveGasPrice as gasPrice in London txs. It will only compute and return the value in the receipt object.

[karalabe]

It's not fully clear to me what gasPrice should return now for 1559 txs? Should it be set to 0? Should it be completely omitted? Seems a bit dangerous to drop straight away and any code depending on gasPrice will insta-break. Should we perhaps keep it synonymous to effectiveGasPrice in the receipt and call it deprecated until people switch over?

[karalabe]

Also worth noting that digging up a receipt is expensive and if you only want to get the price paid, it's a bit of an overkill to do a database lookup just to get a field that doesn't even need any data whatsoever from the receipt.

[MicahZoltu]

I like dropping it. We will likely continue to have more and more new transaction types over time, and not all of them will be able to backfill old properties with reasonable values. If we backfill this time around, people won't write code that is resilient to future transaction changes and they will break in the future rather than today.

Given that there are probably (hopefully) more future Ethereum dapp/integration developers than there are today Ethereum dapp/integration developers, I would rather break today users than future users (e.g., train them now, while it is less damaging).