fix(webhook): check probes and scrapeconfigs RBAC only when CRDs exist

[u-kai]

Description:

The webhook RBAC check for PrometheusCR only warned about servicemonitors and podmonitors,
missing probes and scrapeconfigs.

Also, warnings were emitted even when prometheus-operator was not installed in the cluster.

This fix dynamically discovers which monitoring.coreos.com CRDs exist in the cluster via the
discovery API, and only includes those in the RBAC check.

Clusters without prometheus-operator installed will no longer receive false-positive warnings.

Link to tracking Issue(s):

• Resolves: Incomplete RBAC validation for target allocator scrapeconfigs and probes permissions #4456

Testing:
Updated unit tests in targetallocator_webhook_test.go and collector_webhook_test.go to cover the new dynamic CRD discovery behavior, including a case where no prometheus-operator CRDs are installed (zero warnings expected).

Documentation:

[swiatekm]

Rather than doing this in the webhook, detecting these should be a part of the autodetect package. Right now we store a PrometheusCRAvailable boolean value in the config, whereas it should be a list of the available CRDs. Then the webhook would just pull it from the config. This may require some refactoring along the way.

[u-kai]

@swiatekm
Thanks for the comment!
I've fixed the code following your advice.

[jaronoff97]

why is this being removed? this is the pattern we follow for this so we have a well typed signature. We could instead add multiple values here for each of the CRDs we care about checking.

[u-kai]

Thank you for the comment.

The reason for using []string instead of extending Availability is that the value is consumed directly as rbacv1.PolicyRule.Resources (which is
[]string), so keeping it as []string throughout avoids any type conversion at the call site.

That said, would it make sense to introduce a named type like type AvailableCRDs []string as a lightweight wrapper to preserve the well-typed
signature pattern used elsewhere in this package?