Stop e2e metric scrapes depending on a Docker Hub pull per pod

The e2e suite reads metrics by creating a pod from curlimages/curl:latest, as in test/e2e/limitrange_test.go:254:"name":"curl","image":"curlimages/curl:latest", with five more uses in that package. A latest tag defaults to imagePullPolicy: Always, so every scrape contacts Docker Hub even with the image cached, and the suite makes several scrapes per spec. A registry or DNS blip therefore fails specs that have nothing to do with it.

Measured on run 42342375340, PR #128 at 58c04fe: scrape pod curl-resize-results-9 stayed Pending for the spec's 180-second timeout, with dial tcp 98.95.191.109:443: i/o timeout, then lookup registry-1.docker.io on 172.18.0.1:53: server misbehaving. The spec's own assertions had passed up to that scrape, and the ordered containers after it skipped. Run 42327594533 passed on the commit before.

The registry may not be the cause. The spec's kubectl get pod polls ran about a second apart until 05:28:34, then took 61s, 62s and 11s, so the control plane stalled for about 2m14s and the pull errors may be another symptom of that. What stalled it is unknown.

The leader exited 1 at 05:28:49, 15 seconds into the stall. Only the restarted container's logs were kept, so its reason is unread. The same exit reproduces with no VPA code: review of PR #128 stopped kube-apiserver with SIGSTOP for 18 seconds on kind and got leader election lost, exit 1, on base 5b80a64 and on 7fd8785. So the failure dump should keep kubectl logs --previous for the manager, which would have answered this.

Pin the image by digest and load it into kind during setup with IfNotPresent, so a scrape makes no external request. The same reasoning applies to any other image the suite pulls per pod. Pinning alone is unmeasured as a fix for this failure, because the stall used 134 of that spec's 180 seconds.