Add exec probe handler support to probes API

[zzzeek]

Add ProbeHandlerType (HTTP/Exec) and Command/Port/Scheme fields to ProbeConf. Introduce SetProbeConfV2 and CreateProbeSetV2 with a self-contained ProbeConf signature that switches on handler type. Export Merge for downstream use. Existing SetProbeConf/CreateProbeSet delegate to V2 for full backward compatibility.

References: OSPRH-30190

[fmount]

@zzzeek not sure about your thoughts but I'd like to consolidate these two switch-case(s) into a single one.
e.g.

switch config.Type {
case ProbeHandlerExec:
    if len(config.Command) == 0 {
        errorList = append(errorList, field.Required(basePath.Child("command"),
            "command is required for exec probe type"))
    }
case "", ProbeHandlerHTTP:
    if config.Path != "" && !strings.HasPrefix(config.Path, "/") {
        errorList = append(errorList, field.Invalid(basePath.Child("path"), config.Path,
            "path must start with '/' if specified"))
    }
default:
    errorList = append(errorList, field.Invalid(basePath.Child("type"), config.Type,
        "type must be one of: HTTP, Exec, or unset"))
}

This default should address the invalid type which is the entrypoint for our check, while the "valid" use cases can check other parameters and eventually raise a specific error.

[zzzeek]

yeah sorry looks like the robot was getting creative here, I spent most of my time fixing up the tests it generated.

[fmount]

I'm wondering if we really need a config.Type. While I understand the purpose and makes things readable, technically you can infer the type from the len(config.Command): if it is > 0 it implies you asked for an Exec Handler type, otherwise http, no other potential choices or extension are allowed AFAIK in k8s.
@zzzeek wdyt?

[zzzeek]

still a python dev I think of "explicit is better than implicit". We discussed supporting other kinds of probes in the future (e.g. expanding the enum to include TCP, GRPC), which means for validation we need a way to validate the mutual exclusiveness of the different handler types and up front we need to know which ProbeHandler sub-field we are looking at. If we support Exec, HTTP, TCP and GRPC all at the same time, it seems like it would be uncomfortable defining a hierarchy of which field sets we look at first to determine the intent, which we then validate on once we've decided on which handler type we think this is. plus as you mention it makes things readable.

in the Probe struct, this mutual exclusiveness is determined by which of the sub-actions inside of ProbeHandler are set. so they dont have quite the same problem since we're working with a flat namespace.

[fmount]

fair enough, it's eventually just a string so it shouldn't impact on the CRD size. let's keep it explicit if the idea is to extend it more over the time.

[fmount]

This is connected to my other comment. In other words I'm wondering if we should infer the ProbeHandlerType from the Command (it must be passed in that case) and default to HTTP (the only other choice) when a command is not passed. The other checks might remain unchanged or enhanced.