[Synthetics] Consider validating client strategy for monitor body

[dominiqueclarke]

Describe the feature:

This ticket is simply to evaluate the use of kbn-schema and io-ts to help with validating monitor bodies for the following apis

• - POST /internal/uptime/service/monitors
• - PUT /internal/uptime/service/monitors/{monitorId}
• - POST /internal/uptime/service/monitors/run_once
• - GET /internal/uptime/service/monitor/inspect (shahzad)

Currently, we do not have any kbn-schema defined for the monitor body. However, we do use io.ts for runtime checking on the body. Since the client monitor body is the same type as the SO attributes currently, io-ts is used to ensure that the body sent is compatible with the SO schema. However, these types will soon be separated and require their own form of compile time or runtime-time type checking.

We need to ensure we have proper type checking in two places:

• The client contract for the monitor configuration
• The SO attributes contract that is saved for the monitor, after it is transformed from the client contract

We should evaluate how we want to use io-ts and kbn-schema for both of these goals.

Is there any reason we should use kbn-schema alongside io-ts? Or should we stick with using io-ts exclusively because of how complicated the monitor types are?

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[shahzad31]

not worth redoing validations in kbn-schema, since we already have io-ts based runtime validation