release: automate orchestration version update

[rail]

Previously, as a part of the release process we had to bump the
orchestration versions using sed with some error-prone regexes.

This patch adds set-orchestration-version subcommand to the release
tool. It uses templates in order to generate the orchestration files.

Release note: None

[cockroach-teamcity]

This change is 

[rail]

The easiest way to review the YAML files would be using git show --find-copies.

How to test:

bazel build //pkg/cmd/release
$(bazel info bazel-bin)/pkg/cmd/release/release_/release set-orchestration-version \
  --template-dir ./cloud/kubernetes/templates --output-dir ./cloud/kubernetes/ --version v21.2.6
git diff 
# should be empty ^
$(bazel info bazel-bin)/pkg/cmd/release/release_/release set-orchestration-version \
  --template-dir ./cloud/kubernetes/templates --output-dir ./cloud/kubernetes/ --version v21.2.7
git diff
# should be expected version bump

[celiala]

Thanks for adding the testing instructions!

Had one thought/question (inline), but it's not-blocking (okay to merge as-is !)

Reviewed 52 of 53 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @rail)

---

pkg/cmd/release/orchestration.go, line 93 at r1 (raw file):

		if strings.HasSuffix(destFile, ".yaml") {
			generatedContents = fmt.Sprintf("# Generated file, DO NOT EDIT. Source: %s\n", filePath) + generatedContents
		}

Here we're only adding the "# Generated file..." line to .yaml files --- shouldn't we add the generated-file note to contents that we generate (not just yaml?).

I'm guessing the intent here is that we don't want the script to break a generated file if someone adds a non-yaml file in the future? If that's the case, should we either return an error for an unsupported generated file type? or if error-ing out is too extreme, we could output a warning or something?

[rail]

bors r=celiala

[craig]

Build succeeded:

• GitHub CI (Cockroach)