Optimize forking's eth_call on blocks before the fork block number

[davidmurdoch]

Related to #1547

Ganache doesn't forward eth_call's to blocks before the fork to the original node, but instead executes everything locally. This means we have to fetch any state that the transaction interacts with at runtime.

A couple of reasons for doing this

1. We plan on allowing users to alter historical state, which requires we run the transaction locally.
2. remote nodes usually have an upper bound for how long an eth_call call is permitted to run. Ganache doesn't currently limit the execution time.

It's often the case that the above reasons don't apply, so waiting 200x longer than you should is annoying just for handling these little edge cases. So I think we should solve them by:

1. setting a "dirtyState" flag and only running locally if historical state has been altered.
2. try the eth_call via the remote node first (or simultaneously), and fall back to local only if it fails due to timeout reasons.
   b. this one requires that the transaction we send to the node has all fields resolve, as the node may use it's own defaults for things like gasLimit.

[Zeesna4141]

@davidmurdoch has there been any update on this? I've found myself in one of those edge cases where I'm waiting ~15 seconds before I can continue my script due to the eth_call taking so long :(

[davidmurdoch]

See #4536

[Zeesna4141]

ah, hate to see it :(
I've loved using it, but alas things change! Thanks for the heads up, good luck on your future ventures!