[Heartbeat] Support google cloud storage for suites

[andrewvc]

In #29917 (discovery mode) we'll want to enable the use of google cloud storage for downloaded suites, where after the discovery phase we upload the zip, and during the execution phase we pull a zip from GCP instead of a standard URL.

During the discovery phase we need to support cloud storage for a new discovery.source_cache option as in the example below. Note that we only need to support pre-signed URLs for our purposes.

heartbeat.monitors:
 - id: elastic-monitor
  name: Elastic Monitor
  discovery:
    enabled: true
      # optional, place to re-upload the downloaded zip for subsequent executions.
    source_cache:
      gcp_cloud_storage:
        signed_url: "http://presignedurl"
  schedule: '@every 1m'
  source:
    zip_url: 
      url: "https://github.com/elastic/synthetics-demo/archive/refs/heads/main.zip"

During execution we need to support this option as a source type, where it can entered as such:

heartbeat.monitors:
 - id: elastic-monitor
  name: Elastic Monitor
  source:
    gcp_cloud_storage:
      signed_url: "http://presignedurl"
      deps_preinstalled: true # disable the NPM install because it's already correctly bundled in the zip
  schedule: '@every 1m'

[elasticmachine]

Pinging @elastic/uptime (Team:Uptime)

[vigneshshanmugam]

I am actually in favor of calling them cloud_storage as opposed to leaking cloud provider information on the fields. We could add provider metadata as a sub field. Thoughts?

Example:

heartbeat.monitors:
  source:
    cloud_storage:
      provider: gcp
      signed_url: "http://presignedurl"
  schedule: '@every 1m'

Also, we haven't explicitly mentioned how Heartbeat would only run a single journey when invoking the Synthetics while running in the discovery mode for suites. Is it going to filter journeys by name or tags? Can we also add here to the proposal so it completes the whole model.

[paulb-elastic]

@andrewvc is this a dupe of 30295?

[andrewvc]

Yep ,closing as dupe of #30295