Support BlockHash in contract bindings

[ajsutton]

Rationale

To allow users of contract bindings to get a consistent view of the chain across multiple calls it would be useful for bind.CallOpts to support a BlockHash option instead of just BlockNumber. This also allows callers to track changes in specific blocks more easily - for example if they're subscribed to head or log updates and then requesting additional data from the contract, they could do so with block hash, whereas block number may return incorrect data if there is a reorg.

Implementation

Happy to implement this if it is something that would be accepted upstream.

I'd suggest following the same pattern as the pending block support uses by introducing a new bind.BlockHashContractCaller that provides the required CallContractAtHash and GetCodeAtHash (GetCodeAtHash would also have to be added to ethclient.Client but the underlying eth_getCode rpc method already supports passing a block number or block hash).

Like pending calls, if a CallOpts.BlockHash is specified but the backend doesn't implement BlockHashContractCaller an error would be returned. It would also be an error to specify both BlockHash and BlockNumber.

[holiman]

Happy to implement this if it is something that would be accepted upstream.

Triage discussion: yeah, sounds good to us!