[ResponseOps][Connectors] UI schema validation improvements

[jonathan-buttner]

The actions framework provides validation support through a validate function when defining the ConnectorTypeModel. I think the validation functionality could benefit from a few improvements:

1. It would be helpful to leverage the schema defined on the server for validating the form in the frontend. This would reduce duplicate logic.
   • The issue here is the server leverages kbn-schema which uses Joi, which may not be supported by all browsers and importing it would add ~500KB of data to page loads
   • It'd be great if we could let the connector developers use any validation library instead of requiring kbn-schema
2. The sub action framework also requires kbn-schema, it'd be helpful to let developers use any validation library
3. I believe the validateParams function is execute after editActions updates the actionParams passed to component props. It would be helpful to provide validation functions which could be executed prior to the actionParams being updated.
   • The Opsgenie connector's JSON editor required validation prior to calling editActions because invalid fields could cause the form part to crash if the fields were not the right types

[elasticmachine]

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

[cnasikas]

cc @mikecote

[mikecote]

Thank you for the feedback, @jonathan-buttner!

[pmuellr]

Agreed the validation stories for connector / rule params is not great.

But it turns out the validation is not tied to kbn-config-schema, we just happened to pick that as our validator when we built alerting, and we adopted their validation signature as our "contract". So, you should be able to provide an object with a validate(thing-you-are-validating) => validated-thing or throw error as the "schema".

I believe both SIEM and o11y use io-ts etc for validation, for rules, and I'd hope whatever they did there will work for connectors as well. I'm not sure we've used that for any connectors though.

[pmuellr]

As a longer-term story here, I think the rules-as-code effort (for example, using Terraform to manage rules) is going to impact these things, as we likely won't be able to depend on kbn-config-schema for validation, at least completely. Seems like work-around suggested by me ^^^ will hold us until then.