Stop using latest and start using tagged version via semantic releases

Summary

Previously we only had one job which was bumping latest no matter where it would run from, anytime the CI_COMMIT_BRANCH would be present with a Dockerfile, which is not a great pattern.

This change introduces the concept of semantic-releases via the semantic-release/gitlab library: https://github.com/semantic-release/gitlab/

I've introduced it here as an opportunity for our team to experiment with semantic-releases in a project that is not super critical.

Implementation

I've configured our CI/CD pipelines to:

• Run the semantic release in dry-run mode if: $CI_PIPELINE_SOURCE == "merge_request_event". I.e., only the publish-dryrun job will be executed in MRs.
• Run the semantic release in execution mode if: $CI_COMMIT_BRANCH && $CI_COMMIT_REF_PROTECTED == 'true' && $CI_PROJECT_PATH == 'gitlab-org/distribution/issue-bot' && $CI_API_V4_URL == "https://gitlab.com/api/v4". I.e., on protected branches, the publish jobs will be triggered to run the semantic-release and bump our tag versions based on the latest semantic commits on that branch.
• Finally, only - if: $CI_COMMIT_TAG, which pipelines for it will be automatically created by the publish job, as it would create tags, then we create the image version tags for the new tag by copying, using crane, the latest image built for that commit sha, into the new tagged image version.

In the first publish, the semantic-release lib would start by bumping 1.0.0 or 0.1.0 depending on how we configure it. But to better test this MR I've already manually pushed a 0.1.0 tag, so that we can clearly validate that the job will detect the feat: prefix on my commit, and bump the version to 0.2.0.

Related Issues

Closes #25 (closed)

Properly releasing versioned images via CI will also support &83 (closed) once we mirror this project to .org.