[RAC] Add higher-level helper to ruleRegistry plugin exports

[jasonrhodes]

Related:

• [RAC] Initializes Metrics and Logs rule registry setup
• [Uptime] migrate to observability rules registry

In Logs and Metrics, we're just using the basic ruleRegistry flow for now. I think it's a smart idea to provide access to the lower-level primitive methods for creating index templates, etc., especially as we start to take advantage of fields, but I think we could find a middle ground for an API that is similar to what we had before but without going all the way back to wrapping the entire alerting framework's API and becoming our own framework, if we don't want to do that.

I'm thinking it would be nice to have an API like this:

// in plugin's setup method, store this somewhere
const createLifecycleRuleType = plugins.ruleRegistry.createLifecycleRuleTypeFactory({
  appName: "logs",
  mapping: {}
});

// in rule registration
return createLifecycleRuleType({
    id: METRIC_THRESHOLD_ALERT_TYPE_ID,
  name: i18n.translate('xpack.infra.metrics.alertName', {
    defaultMessage: 'Metric threshold',
  }),
  validate: {
    // ...
  },
  minimumLicenseRequired: 'basic',
  executor: async ({ services, params }) => {
    // ...
  }
});

This encapsulates the logger, the cluster client, the need for core.getStartServices, the index and component template creation, the check for isWriteEnabled, and everything about the rule data client inside of the ruleRegistry plugin until I need it. (I'd also be okay with starting out with something like const { createLifecycleRuleType } = plugins.ruleRegistry.createLifecycleRuleTypeFactory() so we can add to the return of that factory function over time ...)

This pattern currently aligns with what we're doing for our Logs/Metrics rule types and seems like it'd work for the Uptime rule type registration, also.

[dgieselaar]

Agreed that a helper (for the bootstrap process) is more than useful here. I'm not sure if appName or mapping should be tied into the lifecycle rule type helper though. I think we'll fairly quickly end up writing different rule type helpers, that all want to use the same mappings/appName.

[jasonrhodes]

Makes sense, @dgieselaar -- I am mostly trying to avoid leaking the RuleDataClient abstraction to my plugin if I don't really need to use it, i.e. receiving it only to pass it back to something from the ruleRegistry plugin. Maybe a class that retains a reference to its client would allow for this?

const ruleRegistration = new RuleRegistration({
  appName: "logs",
  mapping: {}
});

const createLogsRuleType = ruleRegistration.createRuleTypeFactory();

ruleRegistration.client.getReader().search() // etc.

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)

[jasonrhodes]

Done by @banderror