Rule definition should indicate rule configurability

[f1ames]

With https://github.com/kubeshop/monokle-core/pull/373 and then https://github.com/kubeshop/monokle-core/pull/387 we have rules configurability and real use case where such rules are used.

The configuration is done through optional configuration element (2nd element of rule definition array):

rules:
  practices/high-available: ["err", 5]

The issue is that rule definition does not provide any flag/data on configurability, meaning any integration with validation plugin with such rules would need to either guess or have rule ids hard-coded to handle those case and to provide resonable UI/integration.

My proposal would be to at least provide a flag in rule definition, stating if rule can be configured. It would be nice to also have field describing what type of data is expected (be it string, number or any kind of list) so that integrating system can provide proper UI for configuration.

---

Rule definition:

https://github.com/kubeshop/monokle-core/blob/86651f6f046a61a5cd75dc8a11e418a45830dba5/packages/validation/src/common/sarif.ts#L95-L117

https://github.com/kubeshop/monokle-core/blob/86651f6f046a61a5cd75dc8a11e418a45830dba5/packages/validation/src/common/sarif.ts#L140-L169

[f1ames]

After some thinking, for any UI to be build from configurable rules, it will be good to have:

• indication saying that rule is configurable
• expected input type
• input name - like Expected name, Expected labels, Number of replicas, etc, sometimes it can be assumed from rule definition but it might be confusing
• default input - to always be aligned with expected type and also to not to hardcode it in rule code

So that could look like:

export type RuleMetadata<TProperties = {}> = { 
  id: string; 
  name: string;
  ...;
  configurability: {
    type: string; // or enum like ('number', 'string', 'string[]', 'number[]')
    name: string;
    defaultValue?: number | string | string[] | number[]; // (should be aligned with allowed `type` values)
  }
}

Not sure about configurability key name, but we already have defaultConfiguration (and configuration after rules are processed). For type probably we can use string describing type. I think trying to type this with TS types and e.g. generics will be more cumbersome to implement and then use.

Based on the setting above, a configuration UI can be created which has configuration name for user clarity, knows what type of input control to render and can fill it up with default values.