Scope test-suite readiness checks to KubeVirt's recognized dependencies instead of all cluster pods

Is your feature request related to a problem? Please describe

SynchronizedBeforeSuite gates the entire functional test suite on waitForAllPodsReady and waitForAllDaemonSetsReady (tests/testsuite/fixture.go), both of which list pods/daemonsets across all namespaces (k8sv1.NamespaceAll) with no filtering whatsoever — no label selector, no namespace scoping. If a single pod anywhere in the cluster is not ready, the whole suite fails to start, even if that pod has nothing to do with KubeVirt.

In practice this means the suite's startup depends on the health of arbitrary cluster components it has no relationship with — for example, a monitoring or logging agent installed by the cluster/distribution, unrelated to KubeVirt, can block every test job by being unready. A distribution may also install KubeVirt's own dependencies (e.g. CDI) under differently-named or shared namespaces, so a fix can't simply assume fixed namespace names either.

This is a known, recurring issue, not a new observation — it was raised twice before and both attempts were closed unmerged:

• #2653 — "Relaxes the wait for pods in entire cluster"
• #3461 — "RFC: limit utils.WaitForAllPodsReady to kubevirt's own namespace" (2020)

#3461 was closed as "too simplistic" — the reviewer asked for filtering by pattern/label/namespace rather than a blanket namespace substitution, but the discussion stalled without a concrete follow-up.

Describe the solution you'd like

The underlying principle: the test suite should only gate startup on its own recognized, direct dependencies — today that's KubeVirt itself, and CDI when it's installed. It should not act as a general-purpose health gate for arbitrary services a given cluster happens to run. Concretely:

1. KubeVirt: EnsureKubevirtReadyWithTimeout already waits on the KubeVirt CR's Available/Progressing/Degraded/Created conditions, and is already called independently in SynchronizedBeforeTestSetup. This is a complete, namespace-name-agnostic signal (the namespace is auto-detected from the cluster-scoped CR) — no blind pod scan is needed for KubeVirt itself.
2. KubeVirt's own DaemonSets (virt-handler, plus the disks-images-provider test-support DaemonSet): scope waitForAllDaemonSetsReady's list call to the (already auto-detected) KubeVirt install namespace instead of NamespaceAll.
3. CDI, when installed: add an analogous EnsureCDIReady() that waits on the CDI CR's own conditions. The CDI CR is cluster-scoped and uses the same generic condition vocabulary as KubeVirt's CR, so this check needs no namespace name at all — it works regardless of where CDI's control-plane pods actually run, which avoids relying on a possibly-incorrect namespace flag.
4. Test-owned namespaces (kubevirt-test-*): keep a narrow pod-readiness check limited to these fixed, test-framework-owned names, mainly as a safety net against leftover pods from a previous run.
5. Remove the cluster-wide (NamespaceAll) pod/daemonset checks entirely, and do not gate on generic platform namespaces (e.g. a cluster's monitoring stack, kube-system) — those aren't KubeVirt's or CDI's dependencies to police.

This is a starting proposal, not a final design — happy to have the approach challenged or reshaped by anyone more familiar with the history here.

Describe alternatives you've considered

• A cluster-wide label selector (closer to the original #3461 ask) instead of per-component CR conditions — viable, but requires consistent labeling conventions across all recognized dependencies that don't fully exist today.
• A namespace denylist — rejected as fragile/reactive; it just inverts the same maintenance burden.
• Removing the check entirely — rejected, it would lose real detection of broken test infrastructure (e.g. CDI itself down) with no replacement signal.
• A fixed namespace allowlist (KubeVirt namespace + CDI namespace + test namespaces) — the simplest option, but relies on the CDI-namespace value being correct, which isn't guaranteed across all installation layouts. Worth discussing as a lower-effort fallback if the CR-condition approach turns out to be more work than it's worth.

Additional context

No open issue or PR currently tracks this (checked via issue/PR search) — filing this to restart the discussion with a design that directly addresses the objection that stalled #3461.