fix(ethapi): make eth_getTransactionReceipt null for unexecuted/unknown transactions

[cryptoAtwill]

This one addresses #1003.

From the issue above, it seems the txn hash is found but the block information is not found. This could be the latest block is not yet confirmed. This PR checks if block header is found when txn hash is present, it will return None. Else if the block header is found but block data is not found, it will throw an error.

[raulk]

Is there a test you can augment with these scenarios?

[raulk]

When can this happen? When the transaction we requested was a system transaction? Eg top-down finality?

[raulk]

Do those not have a receipt we can return?

[raulk]

It sounds reasonable for an app to find this tx in an explorer or via the block API, then request its receipt. Not returning it breaks assumptions, but returning an error will cause breakage, I'm sure.

[cryptoAtwill]

The other kind of message is IPC mesage, which I believe the receipts are not handled like signed txns, we might not get a proper txn receipt. Or we can just return None regardless of whatever error and just log these error using metrics

[raulk]

Can we call this var tx?

[raulk]

@cryptoAtwill We don't seem to have structured integration tests for the Eth API, so covering this in a test case is a non-starter for now. Did you successfully test this manually?

[raulk]

Pending test results from @cryptoAtwill.

[cryptoAtwill]

I have tested this using:

RPC_URL="http://localhost:8545"
txn_hash=$(cast send --rpc-url ${RPC_URL} --private-key <PRIVATE_KEY> --value 1gwei <ADDRESS> --async)
echo "${txn_hash}"

curl ${RPC_URL} \
  -X POST \
  -H "Content-Type: application/json" \
  --data "{\"method\":\"eth_getTransactionReceipt\",\"params\":[\"${txn_hash}\"],\"id\":1,\"jsonrpc\":\"2.0\"}"

The result I got: {"jsonrpc":"2.0","result":null,"id":1}. I think it will only be triggered under certain race condition, this PR should not have caused extra errors.