proto fields for scripted check enablement

[The-9880]

First in line for restricting scripted/browser checks to enabled probes.

We add a Capabilities structure which contains flags for different 'features' we might enable on probes. The Agent can have a method which takes this structure in and validates its setup against this config.

The first field in here is DisableScriptedChecks which is set if the probe is disallowed from receiving scripted checks to execute.

[mem]

Looking at the other PR (https://github.com/grafana/synthetic-monitoring-agent/pull/675), I'm thinking that whether or not a probe is allowed to run scripts is something that should be set the API level (because the probe is created and available before it connects to the API). The API should tell the probe "you are supposed to run scripts" and the probe can validate that the feature flag is set (or that it's able to run k6, because the binary is available, or it's been provided with a URL for the runner).

So I think the proto message should be extended to include that info, and the API should be extended so that a probe is eligible for running k6 checks or not.

[The-9880]

Looking at the other PR (#675), I'm thinking that whether or not a probe is allowed to run scripts is something that should be set the API level (because the probe is created and available before it connects to the API). The API should tell the probe "you are supposed to run scripts" and the probe can validate that the feature flag is set (or that it's able to run k6, because the binary is available, or it's been provided with a URL for the runner).

So I think the proto message should be extended to include that info, and the API should be extended so that a probe is eligible for running k6 checks or not.

I think that having the API determine if the probe should run the check or not will add some UI overhead and also some friction in toggling this for a probe.

Here are a few of my thoughts:

• Having the probe opt-in via its config (ProbeInfo) upon registration is more flexible - otherwise, I would have to create a 'new probe' on the API and change my token to toggle scripted checks execution.
• It's easy to toggle on/off for our public clusters by updating the config (see this PR).
• We already update probe info in the DB when probes (re)connect to the API, so there's not significant new overhead introduced by making this field reflect the probe's runtime config.

I figure it makes sense regardless to do the same set of validations on a probe if someone enables Feature.K6 on it, but maybe I'm missing something with that.

Edit: though I think if we want some probes to have K6 enabled (i.e. for MultiHTTP checks) but not perform more complex scripted checks, we could add a separate flag for this enablement.

EDIT (4/15/24): we're going with an API-driven implementation - resolving prior threads and updating PR.