Proposal: Investigate tag build "promoting"

Idea:

Runner release tool only creates a tag for a runner release if the pipeline for that commit has already succeeeded.

The pipeline for that commit should have already:

• Made a draft GitLab release (maybe?)
• Tagged images (at least in our own GitLab registry)
• Pushed binaries to bleeding packagecloud repo
• Add release to S3 under draft name

The tag pipeline for Runner does not test or build anything. All building and testing should have already occurred in the pipeline for the commit we're tagging.

The tag pipeline only promotes:

• Publishes draft GitLab release
• Re-tags images (potentially syncs to other registries... or maybe just retags there too. Need to decide)
• The packagecloud 'promote' API is called to promote from bleeding to stable repo
• Promote draft s3 release (aws s3 --recursive mv s3://<bucketname>/draft s3://<bucket>/release). This using the copy and delete operations for each file to effectively rename all the paths.

Benefits:

• Effectively an atomic release
• Tagged pipeline runs super quick. All the hard work is already done.
• Idempotent.

For example, this is approximately how https://gitlab.com/gitlab-org/step-runner releases.