Fix edge case goldToken lookup for epoch rewards at synced head

[eelanagaraj]

Description

Fixes a bug that occurs when the block/transaction endpoint is hit for the epoch rewards tx in an epoch block that is at the synced tip of Rosetta’s node. What happens:

• the monitor service subscribes to block headers and only processes + updates the DB only once it receives the header
  block/transaction tries to compute epoch rewards for the last tx in the epoch block, which requires some information that is processed by the monitor service (which updates rosetta’s internal DB)
• the endpoint tries to query the goldToken contract from the start of the following block (since this is assumed the safest correct address to filter contract logs on to get the transfer events, since the contract address wouldn’t change in between the last tx + start of the next block)
• the bug occurs bc the next block hasn’t yet been received/processed, so errors on fetching the contract address. Retrying the request after the followup block has been received is totally fine, so the bug doesn’t seem tooo critical.
• we see this very consistently when running tests on mycelo networks with shorter epochs, and where it’s possible to really sync to the tip pretty quickly

The fix for this in this PR just looks up the contract address from the tx index of the epoch block. Since this is the last tx in the block, there should not be any other txs that change the goldToken contract address between this and the start of the next block (old solution).

Tested

• reconciliation checks locally with a mycelo testnet
• reconciliation checks locally for several epochs for alfajores
• plan: include this in the next rosetta tests run in k8s -- if this causes unexpected new issues, this does not need to be included in the present release, since this is a small edge case that will succeed on retries anyways, so not a huge issue.
  • so far past espresso HF

[palango]

Not relying on the next block looks like the cleaner solution!