Fix light-mode confirmation manager to check receipts efficiently and reliably

[Chengxuan]

Why these enhancements are required

Light chain-tracking mode was checking every pending transaction's receipt on every notification (not just new blocks), and separately had no way to retry a transaction that wasn't yet mined other than waiting on the stale-receipt-timeout (default to 1 min).

Together these made light mode dramatically slower than full mode for the same workload, and in degenerate cases (e.g. under sustained RPC pressure) could hugely delay receipt processing for the whole confirmation manager.

Changes:

• processBlockHashes now only runs the light-mode confirmation sweep (checkAndDispatchConfirmationsUsingBlockHeight) when the current loop iteration was actually triggered by a new block event, not on every notification.
  • Full mode already had this gate (it no-ops when there are no new block hashes). Light mode was missing the equivalent, since light-mode block events never populate blockHashes directly, only a head-number bump.
• scheduleAllTxReceipts now also fires on every light-mode new-block event, not just the first block the manager ever sees, so a newly submitted transaction gets its first receipt check on the next block instead of waiting out the stale timeout.
• Also extended scheduleReceiptChecks so a transaction still without a receipt (blockHash == "") is retried on every new block, not just checked once. Light mode has no way to know in advance which block will contain a given transaction (full mode gets this for free by scanning each new block's transaction list), so without this, a "not found" result on the first check would fall back to the 60s stale-timeout for every subsequent attempt too.

Intermittent test failure fix

The intermittent test failure came from out-of-order receiptArrived notifications. With 10 parallel receipt workers, an older in-flight check could finish after a newer one, overwriting pending.blockHash with a stale fork

[Chengxuan]

The intermittent test failure caught a bug that an older version of queued receipt check might override the the result of the latest request if the latest request happens quicker that the old one.

Going to introduce a generation counter to discard the outdated result to fix the racing condition

[Chengxuan]

replaced by #176