Custom Functions and expression language

[jerzyn]

The current approach to custom functions has some issues. For once, it means you may end up running someone else's js script, which is not necessarily always safe or fine with your organization's policies. And the second thing is inconsistency with yaml/json.
I propose exploring the adoption of Common Expression Language (CEL). CEL is designed to be embedded as strings inside YAML, is not Turing complete and runs in bounded time. Kubernetes already uses exactly this pattern in ValidatingAdmissionPolicy (expression, messageExpression, variables) (Kubernetes docs), so many API platform teams already know it and lowers slightly the entry barrier.

• Expressions are type-checked and cost-estimated when the ruleset loads; errors point at the YAML line.
• A per-evaluation cost budget (as Kubernetes does) prevents a pathological expression from hanging CI.
• Compiled programs are cached per rule; the hot path is the same as a core function call.
• Remote rulesets that use only expressions can be loaded without executing any JS, which closes the code-execution risk of extends: https://... with functionsDir.

function: expr is just another core function. assert, variables, vars, where and expressionFunctions are new optional keys. JS functions and JS rulesets remain fully supported; the goal is that new rulesets rarely need them.

Here's a generated example

rules:
  path-params-declared:
    given: $.paths[*]
    then:
      function: expr
      functionOptions:
        variables:
          declared: >
            self.parameters.filter(p, p.in == 'path').map(p, p.name)
          used: pathTemplateParams(key)        # Spectral helper: '/pets/{id}' -> ['id']
        assert: variables.used.all(p, p in variables.declared)
        messageExpression: >
          'Path parameters not declared: ' +
          variables.used.filter(p, !(p in variables.declared)).join(', ')