fix: improve parameter definition validation and error reporting

[ryyakobe]

Fix parameter definition validation and error reporting

This PR improves parameter definition validation across all parameter types to properly handle allowedValues and provide clearer error messages.

Fixes: #179

What was the problem/requirement? (What/Why)

There were several issues with parameter definition validation:

1. The validators were rejecting explicit None values for allowedValues, without a clear error message
2. Error location reporting was inconsistent in validation error messages
3. Documentation comments for maxValue parameters incorrectly described them as "Minimum value"
4. Type casting in JobPathParameterDefinition was using the wrong class name

What was the solution? (How)

1. Added explicit validation for None values in allowedValues across all parameter types (String, Path, Int, Float) with clear error messages
2. Fixed error location reporting in validation error messages to use consistent ("allowedValues", i) format
3. Corrected documentation comments for maxValue parameters to say "Maximum value"
4. Fixed type casting in JobPathParameterDefinition to use the correct class name
5. Added test cases for both implicit and explicit None handling

What is the impact of this change?

This change ensures that:

1. Explicitly set None values for allowedValues are properly rejected with clear error messages
2. Implicitly omitted allowedValues continue to work correctly
3. Error messages are more consistent and accurate across all parameter types
4. Documentation comments correctly describe parameter constraints

How was this change tested?

Added test cases for both implicit and explicit None handling across all parameter types. All existing and new tests pass successfully.

• Have you run the unit tests?
  Yes, all unit tests pass.

Was this change documented?

• Are relevant docstrings in the code base updated?
  Yes, fixed incorrect documentation comments for maxValue parameters.

Is this a breaking change?

No, this is not a breaking change. It improves validation to reject invalid inputs that should have been rejected before, while maintaining compatibility with valid inputs. The error message itself has changed, which could be considered a breaking change but the benefit should be worth it. Compare:

'NoneType' object is not iterable

to

allowedValues cannot be None. The field must contain at least one value or be omitted entirely.

Does this change impact security?

• Does the change need to be threat modeled?
  No.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate failed

Failed conditions
7.3% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[ryyakobe]

Before, the error included allowedValues twice for JobPathParameterDefinition:

'loc': ('allowedValues', 'allowedValues', 2)

After:

('allowedValues', 2)

This is now also consistent with JobStringParameterDefinition and other job parameter types as well.

[baxeaz]

Omitting we intend to be legal which makes sense - but we consider that "implicit None" rather than "implicit Any" or similar? In our code we test for None as an error case, so None even implicitly seems odd that our tests are saying it should be valid

[ryyakobe]

Would renaming this id to allowedValues not provided address your comment?

[baxeaz]

Yep that would work!