add new push-node.sh that uses pre-compiled upstream releases

[BenTheElder]

much faster using official upstream release bits, we'll still want to use the old one for <v1.31.0 (to avoid having larger images) but for v1.31.0+ we can switch to this one.

FYI @aojea

tested with hack/release/push-node.sh v1.31.4 (which pushed to gcr.io/k8s-staging-kind/node:v1.31.4@sha256:7ed51d914668aab502b66f2a82d824be627b4bcd3653f3a119f2bc25f49b81b0)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: BenTheElder

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:

• OWNERS [BenTheElder]

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

[stmcginnis]

/lgtm

[stmcginnis]

Can we always assume we will be in a git repo and not running on a downloaded copy of the source? If so, might be slightly safer to use git rev-parse --show-toplevel.

[BenTheElder]

This approach is safe unless we move the script relative to the repo root, we use it pretty widely in Kubernetes. BASH_SOURCE[0] will be the script invoked and is reliable vs $0 or something like that.

It also works with a downloaded source tarball, for this particular script maybe we don't care, but I prefer using a consistent pattern, and for other scripts some packagers are using tarballs IIRC. (though we currently also have #3645)

This trick is a neat combination of things that are safe versus the more trivial dirname "${BASH_SOURCE}"

1. we use a subshell, so we can CD without affecting the current working directory (and we'd want that anyhow to capture the output)
2. we use CD + pwd -P to portably resolve the real path (versus something like realpath/readlink that are portability nightmares)
3. we use BASH_SOURCE[0] to specifically get the primary source script in a supported way instead of depending on something like "$0 will probably maybe have it"

[BenTheElder]

(pwd -P happens to be specified in posix: https://pubs.opengroup.org/onlinepubs/007904875/utilities/pwd.html and that flag forces it to resolve symlinks, but only for the current working directory)

[BenTheElder]

The main downside of this approach is you need to know the levels of nesting to the repo root (/../..) but that only needs changing if we move it to be more or less nested (like this, the other script is /../../..), which won't happen often and you're going to catch the first time you run the script after moving it.

[BenTheElder]

(er and BASH_SOURCE is safe because we specifically use #!/usr/bin/env bash and bash specifies this, we usually require bash for development scripts in kubernetes (along with gnu coreutils), I use POSIX sh for some portable utilities that I want end users to run, like the local registry script, but it lacks a lot of modern features and is avoided in favor of bash, go, etc otherwise)

[BenTheElder]

... also I think git rev-parse --show-toplevel doesn't work for git worktree, which is something we're starting to use more in Kubernetes scripts (e.g. for diffing codegen in verify scripts)

... I've spent way too much time hacking on these scripts :^), we should really write more of this down somewhere ...

[BenTheElder]

(it started as a copy, I added VERSION="$1" and then ripped out all of the kubernetes build and version detection bits in favor of passing this as the kind build node-image argument)

[BenTheElder]

/retest
[prow build cluster pod scheduling timeout again, no test failures]