Support configurable default parameters via application config

[akashdw]

Pull Request type

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes (Please run ./gradlew build --write-locks to refresh dependencies)
• Other (please describe):

NOTE: Please remember to run ./gradlew spotlessApply to fix any format violations.

Changes in this PR

Default parameters currently ship only as packaged classpath resources under maestro-engine/src/main/resources/defaultparams/. This PR lets them be overridden or extended from Spring application config, so a deployment can adjust defaults without editing the bundled files or forking them.

A new maestro.default-params config carries a YAML blob per category (workflow, step, dry-run, and per step type). Each blob is merged onto the bundled defaults by parameter name, using the same YAML mapper already used to read the resource files. Behavior is unchanged when no config is present.

maestro:
  default-params:
    workflow: |
      cluster:
        value: staging
        type: STRING

For example, the same default parameter often needs a different value per environment. Setting a cluster default to staging in the staging cluster, and to the production cluster name in production, lets each deployment supply its own value in config rather than by patching the packaged defaultparams/*.yaml. cluster is only an illustration; any default parameter can be overridden or added the same way.

[rdeepak2002]

Thanks for the PR, this is a good step toward making Maestro more configurable

[out of scope of this pr] Along those lines, I’ve also noticed other areas of the codebase that are hard to extend, such as the StepType enum. For example, if someone wanted to introduce a new step type, they’d have to modify that enum directly, as there’s currently no straightforward way to "register" a new step type.

[praneethy91]

LGTM