This change adds infrastructure for the tag and publish steps in the Release Process. Each of these are run via Cloud Builder so I've made changes so the files can share the implementation. The following is the high-level call pattern of how things typically execute:

The invoker (usually the "Release Process")

The caller (if they don't already have a source tree present) needs to do a "repo init" and "repo sync" and then run 1 (or more, though not typical) of:

• release/start_gcb_build.sh
• release/start_gcb_tag.sh
• release/start_gcb_publish.sh

The steps run to request a "build" (an actual build, a tag, or a publish) from Cloud Builder (CB):

For a build:
release/start_gcb_build.sh uses run_build (in release/gcb_build_lib.sh) with
release/cloud_build.template.json, which has CB run repo, cloud_builder.sh,
update_and_create_archives.sh, store_artifacts.sh.

For a tag:
release/start_gcb_tag.sh uses run_build (in release/gcb_build_lib.sh) with
release/cloud_tag.template.json, which has CB run repo, publish_release.sh (the steps for
publishing to gcs/gcr/docker/github are disabled).

For a publish:
release/start_gcb_publish.sh uses run_build (in release/gcb_build_lib.sh) with
release/cloud_publish.template.json, which has CB run repo, publish_release.sh (the step
for tagging on github is disabled).

Commons/shared to the above 3 build/tag/publish:
release/gcb_build_lib.sh: This is the common functionality for making a build request out of a template
file, requesting a build, and then optionally waiting for the build to complete.
release/json_parse_shared.sh: This file is the shared ugly code for trying to hackishly parse json in bash
using minimal outside dependencies.

Steps run inside Cloud Builder

For a build:
release/cloud_builder.sh: runs push-debian/push-docker/upload-istioctl,
renames *-release.deb files to .deb
release/update_and_create_archives.sh: This script calls install/updateVersion.sh and
create_release_archives.sh twice. The first time is to create a set of "testonly"
tar files that point to the staging location, the second time creates a set that
point to the release location (though the location won't exist until publish is run).
release/create_release_archives.sh: creates the tar files. I adjust the script to
now expect istioctl- under istioctl/ .
release/store_artifacts.sh: Uploads files to GCS/GCR. I adjusted the script
to gzip the docker tars.

For a tag or publish:
release/publish_release.sh:
This is the top-level script run in CB for doing a tag and/or a publish. I try to do certain tasks
in this script so that other scripts only need to work from a local directory (to help address
any concerns from files being dependent on google infrastructure). The script optionally copies
a github token file from GCS to a local temp directory, and then it then optionally performs a
decryption of a github token file (using kms in Google Cloud). The staged build is optionally
copied from GCS to a local directory). After this point the script mostly works out of the temp
directory. The script then does 1 or more of: copy files to GCS, push to GCR/docker, create a tag
on github (using release/create_tag_reference.sh), create a release on github (using
release/create_github_release.sh).
release/create_tag_reference.sh:
This script makes tags and references on github using the github REST API. Currently it tags only
istio proxy but can be later changed to tag all the repos once the build is eventually changed to
builds using what's in the repo manifest rather than what's in the bazel WORKSPACE file.
release/create_github_release.sh:
Creates a draft release on github using a github token [file] and a local directory that contains the
build artifacts. The caller specifies the repo and sha for the release (and also typically populates
the local directory from the GCS staging dir).

Changes to prior build behavior

• Artifacts were mostly staged in a flat directory structure (other than the newly-introduced
  docker tar files going under docker/), but now debian files are in /deb and istioctl-* are in
  /istioctl .
  • This change makes the staging directory consistent with the release directory.
  • This reduces unnecessary inconsistencies (if you were to "stage" directly to a
    release location then fewer, if any, things should be broken).
  • This also fixes the URLs cited in the "testonly" tar files (which were using the /deb
    and /istioctl subdirs).
• Docker tar files are now gzipped. This lengthens the time of the build by a minute
  (I'm tempted to gzip the files as they're generated but I'd have to touch the various
  push-docker scripts in istio and proxy repos), but halves the size of the files and makes
  other steps go faster (offhand I can't say if the net time change is a gain or a loss).
• Remove the -release suffix from the basename in debian images. I'm told this was
  a manual step in the 0.2 releases.
• Adds infrastructure for a tagging step (on github) and a publishing step (to
  gcs/gcr/docker/github).
  • TODO: add somebody's (or some bot's) github token to istio-secrets
• The build, tag, and publish steps all use CB builds and have a need to parse json, so
  I've moved the functionality into a consolidated functionality in gcb_build_lib.sh and
  json_parse_shared.sh.
• Added functionality for storing some one's (or some bot's) github client token in istio-secrets.
  I've currently implemented it to use the same encryption key as the docker file ("DockerHub").
• I updated the text template that's used for github releases. The template now contains URLs
  to the debian images (previously these files were just uploaded) and now when you view the
  draft they're clickable URLs (github doesn't like whitespace between the "text" ).
• I've reduced the amount of static code that lives in the top-level caller (i.e., Release Process
  run via airflow). Previously there was build-launching script that used repo tool to
  grab the build template. Now most of the build-launch script is obtained via repo tool and
  that script now uses a template that was grabbed at the same time. So, the only thing
  that now lives in the top-level is a few calls to repo tool and a call to the build-launching script.
• Some scripts tool a GCR/GCS bucket and subdirectory as separate input parameters, while
  others took them as a combined "bucket/subdir" parameter. I've updated the former to the
  latter.

NONE