Stop building k/cloud-provider-gcp if all you are doing is building k8s clusters

[upodroid]

Every time kubetest2 gce is ran, the entire k/cloud-provider-gcp repo is built when all we are doing in some situations is either testing a prebuilt version of Kubernetes or building just k/k code.

I want to eliminate the legacy-mode flag by copying all the cluster bootstrap logic to the k/cloud-provider-gcp repo.

We are wasting 10 minutes building on every run building k/cloud-provider-gcp when we don't need it.

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_kubetest2/236/pull-kubetest2-gce-build-up-down/1689755384274751488 Is a good example.

[1,722 / 2,284] GoLink cmd/cloud-controller-manager/cloud-controller-manager_/cloud-controller-manager; 18s linux-sandbox ... (8 actions, 7 running)
[2,136 / 2,284] GoCompilePkg vendor/github.com/GoogleCloudPlatform/k8s-cloud-provider/pkg/cloud/cloud.a; 7s linux-sandbox ... (8 actions, 7 running)
Target //release:release-tars up-to-date:
  bazel-bin/release/kubernetes-manifests.tar.gz.sha512
  bazel-bin/release/kubernetes-server-linux-amd64.tar.gz.sha512
  bazel-bin/external/io_k8s_release/kubernetes-node-linux-amd64.tar
INFO: Elapsed time: 603.523s, Critical Path: 374.04s

[upodroid]

/priority important-soon
/sig testing

[upodroid]

Datapoint:
https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_kubetest2/236/pull-kubetest2-gce-build-up-down/1690009806422675456

Omitting build flag doesn't work because the shell scripts are looking for cloudprovider gcp binaries.

kubetest2 gce \
    -v=2 \
    --repo-root="$REPO_ROOT" \
    --build \
    --up \
    --down \
    --test=ginkgo \
    --master-size=e2-standard-2 \
    --node-size=e2-standard-2 \
    -- \
    --test-package-version="${TEST_PACKAGE_VERSION}" \
    --focus-regex='Secrets should be consumable via the environment' \
    --skip-regex='\[Driver:.gcepd\]|\[Slow\]|\[Serial\]|\[Disruptive\]|\[Flaky\]|\[Feature:.+\]' \
    --timeout=60m

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[elieser1101]

Is this still needed?