fix: use adjusted time on estimate gas when latest block is being used

[luzzif]

When estimating gas, use the adjusted timestamp in case the latest block tag is being used. This helps avoid some errors in time-dependent contracts when using Ganache in fork mode.

Should fix #3528.

This is my first PR here, would love some guidance.

[jeffsmale90]

Thanks for opening this!

I've added a couple of thoughts - can you please also add tests to cover this behaviour?

[jeffsmale90]

QUANTITY type shouldn't be used inside of the application logic - it's an alias type that's used to describe parameters in the API layer. Instead, accept type Quantity here, and do the conversion in the caller.

[jeffsmale90]

Seems to me that if the request is for "latest", this should be incrementing the timestamp, otherwise we use the timestamp of the previous block, rather than the "next" block.

[jeffsmale90]

it'd be nice if this were a verb, ie createEstimateGasBlock or something.

I haven't the time to look into this further today, but I wonder if there's some value in combining the readyNextBlock and this function, as they are very similar (it might be that it just becomes too complicated to be worthwhile though).

[luzzif]

A bit of delay on this but... I just implemented the same logic on eth_call on a local fork, but using a slightly different way. I made the readyNextBlock in the blockchain class public and when latest is passed as the block I use that instead of the standard built RuntimeBlock. I wonder if we could simplify the implementation of the eth_estimateGas logic by doing the same here. The only thing we probably need to change is that I noticed that in the eth_estimateGas case the gas limit defaults to the miner's call gas limit instead of the default block gas limit used in the standard readyNextBlock function.