validate/vendor: always tidy
**- What I did**
Prevent #44453 or similar by always running `go mod tidy` when checking vendoring.

**- How I did it**
Allow running individual steps in `hack/vendor.sh` while still using it as the exclusive wrapper for `go mod` by introducing 'subcommands'; the default behavior is identical to the previous (which is now aliased as the `all` subcommand).

Make `hack/validate/vendor` take advantage of these split steps, and refactor it to be more robust against whitespace/follow bash best practices.

**- How to verify it**
Manually; revert #44453 locally to test tidy detection, and commit a modification to a vendored file to test re-vendor detection.

**- Description for the changelog**
N/A

**- A picture of a cute animal (not mandatory but encouraged)**
![](https://cdn.discordapp.com/attachments/704333319697072231/1041724104077750373/78191E84-9FF7-4BE8-9F2D-D94EEEAA48FA.jpg)


hack/vendor.sh
#!/usr/bin/env bash

# This file is just wrapper around 'go mod vendor' tool.
# For updating dependencies you should change `vendor.mod` file in root of the
# project.

set -e
set -x

SCRIPTDIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
"${SCRIPTDIR}"/go-mod-prepare.sh

GO111MODULE=auto go mod tidy -modfile 'vendor.mod' -compat 1.18
GO111MODULE=auto go mod vendor -modfile vendor.mod

#!/usr/bin/env bash
#
# This file is just a wrapper around the 'go mod vendor' tool.
# For updating dependencies you should change `vendor.mod` file in root of the
# project.

set -e

SCRIPTDIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
"${SCRIPTDIR}"/go-mod-prepare.sh

export GO111MODULE=on

tidy() (
		set -x
		go mod tidy -modfile vendor.mod -compat 1.18
)

vendor() (
		set -x
		go mod vendor -modfile vendor.mod
)

help() {
	printf "%s:\n" "$(basename "$0")"
	echo "  - tidy: run go mod tidy"
	echo "  - vendor: run go mod vendor"
	echo "  - all: run tidy && vendor"
	echo "  - help: show this help"
}

case "$1" in
	tidy) tidy ;;
	vendor) vendor ;;
	""|all) tidy && vendor ;;
	*) help ;;
esac

The current docs say to use `hack/vendor.sh` -- I'd rather slowly chip away at technical debt in the build system and think about what would be more maintainable in the long term without adding too much that is "new" before we expose more/depend more on these implementation details.

That all goes to say that I think the status quo here is fine and the long term intention is to replace/refine this further, as we have logic spread out among Dockerfiles, shell scripts, Makefiles, and more, and it's very hard to sustain/reason about.