[ENH] - Update stages schema structure

[viniciusdc]

Feature description

The current schema structure in our project could be more complex and contain several inefficiencies. The initialization and constraints are handled in the init subcommand within the CLI, and there's a base schema for config pre-validation, along with additional schema/models and validators in each stage. This setup has led to:

• Repetitive logic in various parts of the code.
• Outdated and sometimes incorrect conditions across model structures due to the evolution of the Stages component.
  • Just to cite a few issues:
    • #1947,
    • #2405,
    • #2408,
    • #2122,
• Unnecessary re-initialization of models in both the init and deploy commands, which includes reapplying logic to ensure configurations match the YAML files exactly (despite already reading from these files).
  • This is better described here #2064

To address these issues, I propose restructuring the models and related logic as follows:

• Move all models to a new __schema__.py file within each stage.
• Centralize logic required for passing models to Terraform into a new input_vars.py file.
• Simplify the __init__.py file only to include necessary local imports, if required.

This restructuring would look like this within the project directory:

<Stage>
│
├── template/
│   ├── __init__.py
│   ├── __schema__.py
│   └── input_vars.py

Further, the __schema__.py would be designed to supply models to nebari init, and nebari render wherever necessary, supporting the functionality similar to what the InputVars class currently provides.

Value and/or benefit

• One single mode/schema validation process across all source-code
• Better organization and readability for the overall process
• Tidying and refactoring incoherent/duplicate logic statements
• Helps address missing input data when executing basic commands such as init, render, and deploy.
• This should also help streamline our unit tests.

Anything else?

No response

[viniciusdc]

As a future note, I noticed while reviewing some recent PRs that most of our terraform code variables that depend on the node_groups objects do not expect a certain order within the grouping general, user, worker pre-established. Still, there does not seem to be any enforcement in our models to guarantee such ordering.