(CA) leaner go.mod configuration

[jackfrancis]

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

This PR optimizes the go.mod configuration for Cluster Autoscaler, specifically to remove a bunch of unnecessary replace directives. Some of the deletions are directives for packages that aren't actually present in the dependency graph, some are unnecessary because they match the exact version already declared in the require set.

These changes produce no changes in the resultant go.sum outcome.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jackfrancis

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• cluster-autoscaler/OWNERS [jackfrancis]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jackfrancis]

/assign @BigDarkClown

[jackfrancis]

/test pull-cluster-autoscaler-e2e-azure-master

[jackfrancis]

/assign @towca @gjtempleton @x13n

[x13n]

Isn't this one also a no-op?

[jackfrancis]

Good catch, thanks!

[x13n]

Thanks for cleaning this up! Judging from file contents I think one more line might be dropped, so adding a hold. LGTM otherwise.

/lgtm
/hold

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.

[jackfrancis]

@x13n this is ready for another review round, thank you!

[towca]

Hmm, I'm pretty sure the replaces for k/k staging modules were here intentionally, to cover a corner case where CA starts depending on a new k/k staging module.

More specifically, this is my understanding:

1. We want to keep CA's k/k dependencies (k8s.io/kuberentes + the k/k staging modules) in sync, all pinned to one kubernetes version.
2. The replaces guarantee that we always use the pinned kubernetes version. Requirements just specify the minimum version, and a higher one could be picked when building. So we need both a require and a replace for every k/k dependency.
3. All of the k/k dependencies are updated via a script which adds both a require and a replace for them.
4. What happens if we add a new k/k dependency to CA? We need to either remember/mandate adding the replace as well, or remember/mandate running the dependency-upgrading script which adds the replace. But we can avoid the remembering/mandating if we add replaces for all possible k/k dependencies when running the script.

What was the criteria by which you removed the k/k replaces? Maybe points 1. or 2. are not actually true/no longer apply?

[jackfrancis]

Main criteria is making the go.mod easier to reason about (arguably the replaces aren't that much overhead), and setting it up for automated dependabot maintenance going forward.