Installing tools using commit specification bypassing go.mod and vendoring

[liam-verta]

Actual behavior

golang/go#48332 explains how installing tools using go install <tool>@<version> can result in strange and inconsistent behavior where the version of libraries do not match what is present in go.mod and go.sum.

The project recently ran afoul of problems related to this.

Expected behavior

Install tools without using @<version> tagging in the command. Instead, use placeholder imports to make the module system track tools dependency versions in go.mod and go.sum and call go install <tool>. This lets the
dependencies and transitive dependencies versions be controlled using go.mod and go.sum as would reasonably be expected.

To Reproduce
Steps to reproduce the behavior:

• go install github.com/awslabs/amazon-ecr-credential-helper/ecr-login/cli/docker-credential-ecr-login@adf1bafd791ae7d4ff098108b1e91f36a4da5404

The above command does not use the local vendor or go.mod, instead downloading from the external project's repo and doing the same for all dependencies of that project.

Compare to the behavior of #2562. The call to go install github.com/awslabs/amazon-ecr-credential-helper/ecr-login/cli/docker-credential-ecr-login uses the local go.mod and go.sum along with the locally stored vendored dependencies.

Additional Information

• Dockerfile
  Please provide either the Dockerfile you're trying to build or one that can reproduce this error.
• Build Context
  Please provide or clearly describe any files needed to build the Dockerfile (ADD/COPY commands)
• Kaniko Image (fully qualified with digest)

Triage Notes for the Maintainers

Description	Yes/No
Please check if this a new feature you are proposing
Please check if the build works in docker but not in kaniko
Please check if this error is seen when you use --cache flag
Please check if your dockerfile is a multistage dockerfile