Draft: [Version-unspecific] Refactor Solvency & Add HaltChain ExInfo - #check-lint-warning

I'm closing this MR in favor of !698.

Closes #60 (closed) Replacing !395 (closed) Replacing !231 (closed)

The existing solvency checking logic was fragmented and duplicated across each individual chain client. This change introduces a new, centralized ExInfo Dispatcher to orchestrate all external information reporting. It refactors the existing solvency logic and introduces a new Solvency reporter, creating a unified framework. The new HaltChain reporter ensures monitoring and handling of changes to the watched Mimirs on THORChain, specifically those related to halting THORChain itself or the chains it supports.

Key Features and Changes:

1. Centralized Dispatcher:

• A single Dispatcher instance is now the central point for handling all ExInfo checking and broadcasting.
• It manages a collection of "Reporters" (e.g., SolvencyReporter, HaltChainReporter) for each chain.

2. Unified Trigger Mechanism:

• There are two sources that can trigger an ExInfo check:
• BlockScanner: After successfull FetchTxs, each chain's block scanner calls Dispatcher.Process(chain, height).
• Runner: A single, global runner periodically calls Dispatcher.Process() for each chain at a regular interval (specific for each chain) to check for ExInfo (Solvency or Halt chain) when BlockScanner is halted.

3. Synchronization

• Dispatcher.Process() method immediately launches its logic in a new goroutine, ensuring the calling BlockScanner isn't blocked.
• A mutex ensures that only one processing cycle runs at a time.

4. Refactored Solvency Logic:

• All solvency evaluation logic is now consolidated within the exinfo package, removing the fragmented and duplicated code from individual chain clients.
• The old callback mechanism has been removed in favor of the direct Dispatcher.Process call.

5. MAYAChain Integration:

• The Dispatcher collects all ExInfo reports and sends them to MAYANode via MsgExInfo.
• MAYANodethen processes these messages, applying consensus rules based on the ReasonId.
• For HaltChain, a HasMinority() consensus is required (this can be adjusted).
• For Solvency, the MsgExInfo is forwarded internally to the original MsgSolvency handler reusing all existing consensus and processing logic for solvency in MAYANode, ensuring backward compatibility and minimizing risk.

6. Complex testing: This MR includes very thorough unit tests for both SolvencyReporter and HaltChainReporter. It also comes with a robust simulation test for the solvency checker on BTC, ZEC, and ETH chains. The test simulates a real insolvency scenario on an account and observes how Mayanode reacts by evaluating the relevant Mimir values. Then the account is restored, and the test checks whether solvency and normal operation are re-established.

The HaltChain reporter is also carefully tested in simulation test by setting each of the tracked Mimir values on the THORChain node and monitoring Mayanode's response — making sure the changes are correctly picked up and evaluated.

Overall, it's a very thorough test of the entire system in real-world-like conditions.

Summary by CodeRabbit

• New Features

  • Added an ExInfo pipeline with new message types and handlers to report halt-chain and solvency events.
  • New simulation actors and tests to exercise halt-chain and solvency scenarios.

• Improvements

  • Unified dispatcher replaces per-client solvency runners; improved logging, sync, and gas-estimate helpers.
  • Exposed mimir and chain-height helpers for diagnostics and testing.

• Bug Fixes

  • Updated tests and fixtures to align with the new ExInfo flow.

• Chores

  • Removed legacy solvency codepaths and added keeper/storage support for ExInfo voters.