Add Initial Mirage Node Type Support with Dedicated Configuration and Refined Init Checks

[Masterix0]

Problem

The SKALE ecosystem requires support for a new node type, "Mirage," which operates differently from the standard SKALE node.
node-cli needs to be adapted to manage this new node type, including building a specific binary, providing dedicated CLI commands, handling Mirage-specific static parameters, and ensuring core functionalities correctly differentiate behavior, particularly around initialization and resource management.

Solution

This pull request introduces foundational and refined support for the Mirage node type within node-cli.
It establishes a distinct build target for Mirage, introduces Mirage-specific CLI commands and core logic, and significantly refactors shared components to be node-type aware, especially in configuration handling and initialization.

Key Changes Overview:

1. Mirage Build Target & CLI Structure:

   • Introduced build script and CI/CD workflow modifications to generate and publish a separate mirage binary.
   • Added new CLI command groups (mirage boot, mirage node) for the Mirage build type.
   • Implemented core logic for essential Mirage operations (boot init, migration, restore), with other commands reusing existing functionalities.

2. NodeType-Aware Architecture & Configuration Handling:

   • Implemented a NodeType enum (REGULAR, SYNC, MIRAGE) to drive conditional logic throughout the codebase (node management, operations, Docker utilities, Nginx).
   • Introduced support for a dedicated mirage_static_params.yaml for Mirage-specific static configurations, allowing Mirage nodes to use standard ENV_TYPEs (e.g., mainnet, devnet) while sourcing distinct parameters. Core configuration loading (get_static_params) is now NodeType-aware.

3. Refined Initialization and Resource Management:

   • Standardized the node initialization check (is_node_inited) to rely on the presence of nginx.conf, a common artifact for all initialized node types.
   • Ensured that Mirage-specific workflows correctly bypass SKALE's standard resource allocation calculations and shared BTRFS volume setup logic, aligning with Mirage's different resource model.

4. Testing & Documentation:

   • Added and updated dedicated test suites for Mirage CLI commands, core logic, static parameter loading, ENV_TYPE validation, and initialization checks.
   • Updated the README.md to include instructions for the mirage binary, its commands, and its use of standard ENV_TYPEs with the new static parameter approach.

Benefits

• Extensibility: Adds robust support for the Mirage node type, paving the way for future node types.
• Clearer Configuration: Mirage has its own clean static parameter file (mirage_static_params.yaml), simplifying management and avoiding bloat in the common static_params.yaml.
• Maintainability: Encapsulates Mirage-specific logic and uses NodeType for clearer control flow. Shared components like initialization checks and host requirement validation are now more universally applicable or correctly specialized.
• Correctness: Ensures Mirage nodes adhere to their specific operational model by bypassing inapplicable SKALE resource management schemes.
• Alignment: Integrates with corresponding skale-admin changes and the dedicated docker-compose-mirage.yml.
• Test Coverage: Includes dedicated and adapted tests for new Mirage functionality and configuration handling.
• Usability: Provides clear documentation for the mirage binary and its updated configuration paradigm.

Testing Done

• Added new integration tests for Mirage CLI commands (mocking core layer).
• Added new unit/integration tests for Mirage core functions (mocking operations layer).
• Updated environment variable validation tests for Mirage types.
• Adapted existing core/check/utility tests to handle the NodeType parameter and verify behavior across types.
• CI workflows updated to build and test the Mirage binary type.

Reviewer Instructions

1. High-Level Architecture:
   • Focus on the overall strategy for supporting multiple node types via NodeType.
   • Assess the introduction of mirage_static_params.yaml and the NodeType-aware changes to get_static_params.
2. Mirage Workflow & Configuration:
   • Conceptually review how Mirage nodes (boot and regular) source their configurations and initialize.
   • Verify that Mirage operations correctly bypass resource allocation and shared volume logic as intended.
   • Check the updated ENV_TYPE validation for Mirage.
3. Initialization Check:
   • Review the updated is_node_inited logic and its impact on relevant decorators and commands.
4. Testing:
   • Assess the updated test fixtures in tests/conftest.py for both static parameter files.
   • Ensure test adaptations in core_checks_test.py, configs_env_validate_test.py, and Mirage-specific tests correctly reflect the new configuration and initialization logic.
5. Documentation:
   • Verify README.md updates, especially regarding ENV_TYPE usage for Mirage and any mention of static parameters.