Support for lightweight monitors via projects

[andrewvc]

With project monitors we now let users manage browser based monitors easily from the CLI, but that story does not extend to lightweight monitors. This limits the utility of our overall solution since users need multiple workflows, when they ideally could use project monitors for everything if desired.

This issue proposes supporting the YAML format used in heartbeat's monitor.d directory with project monitors. These would act the same as browser based monitors, only their definitions would be YAML based and included in the source tree. An example is listed below.

- type: http 
  id: my-http-monitor
  name: Lightweight HTTP Monitor
  schedule: '@every 5s' 
  hosts: ["https://www.elastic.co"]
  # New keys for service listed below
  locations: ["us-west", "japan"]

Why YAML?

• Users will need to migrate existing configs, this being the exact same format they already use makes migration a breeze.
• Lightweight monitors are more frequently used by administrators who are more comfortable with YAML than JS/TS and Node. Asking users with those personas to use JS/TS may hinder adoption.
• Ease of implementation, should be a simple translation to the API

Gotchas / Known issues

• The IDs are not exactly portable since project monitors include the space and journey in the monitor ID. We could add a special config key preserve_exact_monitor_id: true|false to handle this situation.
• We won't be able to support cron syntax, or, if we do, we should support the subset that is translatable to @every syntax (the regex (\*(\/\d)? )(\*(\/\d)? )\* \* \* should match and capture cron jobs meant to run every N minutes or every N hours.
• Running locally is something we'll need to determine in the future. I propose that we initially just validate these and allow them to be pushed. Later we can determine a strategy for running these locally. Perhaps the simplest answer would be to just invoke docker run in run_once mode. For now, we could just validate the syntax of these monitors locally and mark them in some sort of skipped status.

[dominiqueclarke]

Kibana api for projects does currently assume browser monitor type, so updates to the api would be necessary to parse the type appropriately.

[andrewvc]

See also: #599 and elastic/kibana#140864

[awahab07]

Post FF Testing

init'd a project using the latest build and tried the push command with one browser and one lightweight monitor and it behaved as expected.

1. Returns the error for unsupported fields. For the following yaml config:

   - type: http
     ...
     check.response:
       status: [200]
       body:
         - Text

   it returns
   

2. For duplicate ids, it returns
   

3. When validation passes, it pushes the monitors as expected.

4. However, it always shows the following warning regardless of the schedule value.
   

[vigneshshanmugam]

However, it always shows the following warning regardless of the schedule value.

Yeah this is expected - See #612 (comment)