Don't skip/requeue alerting rules with new "other" fields

[kobelb]

When #158022 was implemented, the approach did not differentiate between the two categories of fields that can be added to the alerting rule schema: parameters and "other". Fields in the parameters category alter the behavior of alerting rules when they run, while fields in the "other" category do not. Using the existing alerting rule schema, the following are examples of fields that fall into the two different categories:

parameters: enabled, consumer, alertTypeId, apiKey, muteAll, muteInstanceIds, throttle, schedule, isSnoozedUntil, snoozeSchedule, actions, notifyWhen, mapped_params, params
"other": name, tags, apiKeyOwner, apiKeyCreatedByUser, createdBy, updatedBy, updatedAt, createdAt, revision, running, meta, executionStatus, monitoring, lastRun, nextRun

When a new field is added to the parameters category, if it's specified then an older version of Kibana that doesn't know about the field should NOT attempt to run the alerting rule. Doing so would result in incorrect behaviors. However, when new fields are added to the "other" category, it's safe for an older Kibana node that doesn't know about the field to run the alerting rule.

Differentiating between these two categories of fields is challenging to do in a backward compatible manner, and the naive approach that I recommended of using a validation schema to detect unknown fields is problematic.

After having a sync and async discussion with @mikecote and @ersin-erdal we decided that we should prototype what it would look like to add an explicit "runtime version" field to the alerting rule. This field would be used to control which versions of Kibana have the capabilities to run specific alerting rules.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[kobelb]

/cc @mikecote @ersin-erdal

[pmuellr]

Looking at #158022 and the mention of follow-on issue #159302 - that issue appears to be closed by the PR that spawned it as a follow-on. So either the comment is wrong - it's not a follow-on, it was implemented here; or the issue somehow got closed accidentally. Or something :-)

Anyway!

I was thinking - we really want to ignore these at the task manager level, don't we? What I was thinking is that each task type could register a modelVersion for it's per-type data - optionally. If set, then we use that when polling for tasks, as a new field in the task doc - taskTypeModelVersion or such. Looking for anythng <= to that. We'd need to add a migration to add that modelVersion for rules and connectors, once we start checking.

Perhaps I'm missing something here though.

[ersin-erdal]

closing in favor of: #176584