test(e2e): run compute e2e on the shared test-infra federation foundation

[scotwells]

What this does

Compute's end-to-end tests now run on the shared test-infra federation foundation (datum-cloud/test-infra#32) instead of a bespoke, compute-only Kind + Karmada harness. Standing up three Kind clusters, installing and tuning Karmada, and joining the POP cells is no longer compute's code to maintain — it's a reusable foundation any Datum service can consume the same way. Compute keeps only what is genuinely service-specific: its Karmada federation config, CRD installs, the management/cell federation credentials, the operator image build, and the deploy overlays. Local task e2e:up on a laptop and the CI job run the identical path, because both pull the foundation in as a remote Taskfile include.

This builds directly on the in-cluster e2e harness from #179 (the deployability work for #149): the operators, overlays, federation credentials, and all nine Chainsaw suites are unchanged — only the cluster/Karmada provisioning underneath them moves to the shared foundation.

Net result: ~620 lines of Karmada/Kind plumbing and four hack/e2e scripts deleted from this repo, the same nine Chainsaw suites still exercising the full federated topology.

What moved where

• Taskfile.yaml — adds a remote Taskfile include of datum-cloud/test-infra (pinned via TEST_INFRA_REF) and delegates cluster/Karmada lifecycle to it. e2e:env:up becomes e2e:tools → infra:federation-up → e2e:karmada:configure → e2e:crds:install; e2e:down → infra:federation-down; e2e:image:load → infra:federation-load-image. The cell-credential step reads the hub's docker-reachable address from the foundation-provided karmada-internal.yaml rather than re-deriving the hub container IP. Deleted: the karmadactl/helm-repo tool installs, cluster-create/kubeconfig-export, and the Karmada install/tune/join tasks.
• hack/e2e/ — deleted (kind-control-plane.yaml, kind-pop.yaml, make-internal-kubeconfig.sh, patch-cluster-secret.sh); all absorbed by the foundation.
• Federation kubeconfigs — now written by the foundation under .test-infra/kubeconfigs/federation/ as compute-control-plane.yaml, karmada.yaml, compute-pop-dfw.yaml, compute-pop-ord.yaml (replacing tmp/e2e/kubeconfigs/* and the downstream.yaml copy). The chainsaw config's named clusters and the referenced-data README are repointed accordingly. The hardcoded --kubeconfig paths inside the Chainsaw suite steps are a path-substitution-only change isolated in its own commit (test(e2e): repoint suite kubeconfig paths…) — no assertion, workload spec, or step logic changes; verify with git diff --word-diff. The relative depth (../../../ from test/e2e/<suite>/) is unchanged because .test-infra/ sits at the repo root just like tmp/ did.
• .github/workflows/test-e2e.yml — opts into TASK_X_REMOTE_TASKFILES=1 at job level, runs task --yes …, drops the manual kind install (the foundation's ensure-tools provides it) and the PyYAML shim (no harness Python parses YAML any more). Diagnostics repointed at the foundation kubeconfig directory/filenames.

Deviations inherited from the foundation

These are intentional consequences of moving onto the shared foundation, each validated by the compute e2e CI acceptance gate:

Area	Before (compute harness)	After (foundation)	Why it's safe
Node image	kind's default node image	pinned kindest/node:v1.32.0 (foundation's K8S_VERSION)	reproducibility improvement; exercised by CI
kind version	manual install of v0.32.0	foundation ensure-tools installs v0.30.0 (accepts any >= v0.30.0)	v0.30.0 supports the v1.32.0 node image
Hub kind config render	sed substitution of the NodePort	envsubst of ${KARMADA_API_NODEPORT}	same rendered config; matches the foundation's existing pattern
Karmada helm install	helm repo add then install	helm install --repo …	avoids mutating the developer's global helm repo list
Kubeconfig rewrite	python3 + PyYAML	kubectl config (unset-CA-then-set)	drops the PyYAML dependency; PP round-trip in the foundation's dogfood CI proves it

Var-naming note: the e2e tool-bin var is E2E_BIN, not the conventional LOCALBIN. A remote Taskfile include's root var clobbers a same-named var in the consumer, and the foundation already defines LOCALBIN — sharing the name rendered compute's value as a nil path. KARMADA_API_NODEPORT is also shared, but it is passed through the include by design and resolves to the same value (local override included, verified 32443→32643).

Verification

Full e2e CI is green on this branch with the foundation pinned to feat/federation-topology: E2E Tests run 29112915347 — foundation-provisioned Kind + Karmada environment, operator image build and deploy, and all nine Chainsaw suites pass. This run doubles as the cross-repo validation for datum-cloud/test-infra#32.

Pinning chain — DO NOT MERGE until re-pinned

TEST_INFRA_REF is currently pinned to the test-infra branch feat/federation-topology so CI can exercise the foundation before it merges. This must be flipped to the tagged foundation release before this PR merges:

1. Add a Karmada federation topology foundation for service e2e test-infra#32 merges first → tag v0.7.0.
2. Flip TEST_INFRA_REF to v0.7.0 here (one var moves both the include URL and the foundation's self-clone ref), re-run compute CI green.
3. Only then is this PR mergeable — and it merges after test(e2e): validate operator deployability with an in-cluster federation e2e #179 (see below).

Stacked on #179

Base branch is feat/e2e-in-cluster (PR #179, which closes #149). This PR is stacked on it and should be reviewed/merged after #179 lands.