fix: add recursive check of cel rules

[timmilesdw]

Overview

This PR enhances the CEL validation logic for OpenAPI schemas in the addon-operator. It introduces recursive validation for all nested properties including for objects with additionalProperties, arrays, and scalar types at the self level, not just the root level, and refactors error handling in more user-friendly approach, returning multiple validation errors at once instead of returning only first encountered validation error.

What this PR does / why we need it

• Recursive CEL Validation:
  Previously, x-deckhouse-validations were only applied at the root level of the schema. Now, the validation logic recursively traverses the entire schema tree, so any x-deckhouse-validations defined at any depth (including deeply nested properties, arrays, and maps via additionalProperties) are correctly processed and enforced.

• Support for Scalar Types and Arrays:
  The validation logic now fully supports CEL rules where self is a scalar (e.g., integer, string, boolean) or an array. This enables writing CEL expressions that directly validate scalar fields or perform aggregate checks on arrays (e.g., self.size() > 0, self < 10, etc.).

• Improved Error Handling:
  The cel.Validate function now returns a slice of validation errors (for failed CEL rules) and a separate technical error (for issues like CEL compilation or type conversion). This makes error reporting more user-friendly.

• Test Improvements:
  Table-driven tests have been updated and expanded to cover cases with nested and deeply nested properties, ensuring that the new recursive validation logic works as intended.

Impact:
With these changes, the product now supports robust, recursive CEL validation for complex and deeply nested configuration schemas. This greatly improves the reliability and correctness of user input validation, allowing module authors to define validation rules at any level of their configuration structure.

Warning

Current code: Does not support oneOf (or anyOf, allOf).

Examples

Before

Validation works correctly, because x-deckhouse-validations is defined at root level:

type: object
properties:
  a:
    type: object
    properties:
      b:
        type: string

x-deckhouse-validations:
- expression: 'self.a.b == "abc"'
  message: "Not equal to abc"

Validation doesn't work at all, because cel.Validate checks only for root level rules:

type: object
properties:
  a:
    type: object
    properties:
      b:
        type: string
    x-deckhouse-validations:
      - expression: 'self.b == "abc"'
        message: "Not equal to abc"

After

Example with x-deckhouse-validations defined at root level has no changes, still works as intended, but example with nested x-deckhouse-validations now outputs a correct validation error:

Not equal to abc

Special notes for your reviewer