Implement clear methodology for config validation checking

[Copilot]

This PR establishes a clear, consistent methodology for where config validation checks should be placed in the Nitro codebase, resolving the confusion between validation logic scattered across config parsing and node creation phases.

Problem

Previously, config validation checks were inconsistently placed across two main areas:

1. cmd/nitro/nitro.go during config parsing and CLI initialization
2. arbnode/node.go during actual node creation

This created confusion about where different types of validation should be placed and could lead to duplicated or inconsistent validation logic.

Solution

Implemented a three-tier validation methodology with clear guidelines:

1. Component-Level Validations

Location: Individual config struct Validate() methods
Purpose: Validate single component configuration consistency
Example: Field value ranges, internal component consistency

func (c *MessagePrunerConfig) Validate() error {
    if c.Enable && c.PruneInterval <= 0 {
        return fmt.Errorf("message pruner prune-interval must be positive when pruning is enabled")
    }
    return nil
}

2. Cross-Component Validations

Location: Top-level config Validate() methods
Purpose: Validate configuration consistency across multiple components
Example: Validator + path scheme compatibility, archive mode warnings

// Cross-component validation for archive mode consistency
if c.Execution.Caching.Archive && c.Node.MessagePruner.Enable {
    log.Warn("message pruner is enabled but archive mode is also enabled - consider disabling message pruner for full archive functionality")
}

3. Runtime/Environmental Validations

Location: Node creation functions (createNodeImpl() and helpers)
Purpose: Validate configuration against runtime environment and external dependencies
Example: Network connectivity, file system permissions, external service availability

Key Changes

• Added MessagePrunerConfig.Validate() - Example of component-level validation with proper error handling
• Enhanced NodeConfig.Validate() - Added cross-component validation for archive mode consistency
• Updated validation call chain - Ensure all component validations are properly called
• Comprehensive documentation - Created VALIDATION_METHODOLOGY.md and docs/CONFIG_VALIDATION_GUIDE.md
• Added tests - Both component-level and cross-component validation test coverage

Benefits

✅ Clarity - Developers know exactly where to place validation logic
✅ Performance - Expensive runtime checks happen only when necessary
✅ Maintainability - Validations are logically grouped and easy to find
✅ Testability - Each validation type can be tested independently
✅ User Experience - Users get validation feedback at the appropriate time

Implementation Status

Analysis shows that most of the codebase already follows this methodology:

• Component-level validations: BatchPosterConfig.Validate(), MaintenanceConfig.Validate(), etc.
• Cross-component validations: Existing validator + path scheme checks in NodeConfig.Validate()
• Runtime validations: Proper placement in createNodeImpl() for connectivity and resource checks

This PR formalizes the approach with clear documentation and examples for future development.

Fixes #503.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.