Retain payment contract bindings with canonical registry-change handling #32

Problem

Node resolves contract addresses through Controller on every payment read. The baseline in builder-core #89 makes nine Controller.getContract calls per paid request. These are part of the 29 sequential RPC calls before dispatch. See Contracts.ResolveAt.

go-livepeer's client.setContracts resolves addresses and retains bindings during initialization. Reuse that setup/binding code where it fits, while preserving node's stronger requirement that reads use the registry valid at their observed block.

Work and acceptance

• Retain resolved RoundsManager, TicketBroker, and BondingManager addresses/bindings outside individual requests. Warm payment requests must not resolve them again.
• Define invalidation or background confirmation for registry changes. Do not assume contract addresses can change only at round boundaries, or silently use startup addresses forever. Coordinate with the shared chain observer below.
• Incorporate the useful improvement from BlueClawNetwork/livepeer-node PR #1: confirm Controller results at the observation's canonical block and use dependent results only under the addresses that block confirms. If a speculative batch uses previous addresses, discard obsolete results and fetch replacements at the same block. Reuse its ABI handling and bounded batch/fallback code only as needed by the chosen design.
• Keep redemption, receipt, and transaction paths correct independently of payment caching. Cache keys/invalidation must respect chain, Controller, contract generation, and block identity where relevant.
• Test warm-request lookup counts, a contract address change within a round, simultaneous address/round changes, reorgs during resolution, and failed/invalid registry reads. No snapshot may combine a new registry address with values from a retired contract.

Depends on shared block/round state #31.

Reuse and attribution

Incorporate existing go-livepeer code as much as possible. Inspect git history and preserve original authorship and git-level provenance through suitable cherry-pick -x commits or a history-preserving import where practical. Where adaptation prevents that, retain license/copyright notices and add inline attribution identifying the source repository, file, commit, and author(s). Apply the same attribution requirements to any retained code or tests from PR #1.