Add Operator release submission validation scripts

What does this MR do?

• Added 2 scripts, olm_manifests.sh and release_validate.sh to help release validation
• olm_manifests.sh wraps kubectl and jq operations
• release_validate.sh calls olm_manifests to check release status

The CI job has been moved to a separate MR !873

Overview of the validation tool

To implement #1261

• olm_manifests.sh is created to wrap the kubectl and js operations.
• release_validate.sh calls olm_manifests.sh to check the releases and create new comments on the release issue.

The scripts contain usage documentation in themselves; more details can be found there.

When a release is created, create_followup_issue saves the release issue ID to its dotenv artifact, and validate_release automatically runs after a 3 day delay.

validate_release can also be triggered manually. The following 5 parameters will be used by it:

• OPERATOR_RELEASE_VERSION: defaults to the commit tag, or must be provided on manual runs.
• OPERATOR_RELEASE_COMMENT: defaults to true; unset this variable to avoid commenting on the issue.
• OPERATOR_RELEASE_ISSUE_ID: read from the dotenv, or must be provided on manual runs.
• OPERATOR_RELEASE_PROJECT_ID: defaults to CI_PROJECT_ID
• OPERATOR_RELEASE_TOKEN: defaults to the release issue bot token
• KUBECONFIG: Used to check OLM releases, defaults to KUBECONFIG_OCP_4_14

An example issue can be found here: https://gitlab.com/lucus.li/playground/-/issues/2#note_1957341034

✅ Catalog operatorhub has version 1.0.0, latest version is 1.0.2

✅ Catalog community-operators has version 1.0.0, latest version is 1.0.2

❌ Catalog certified-operators does not have version 1.0.0, latest version is 1.0.2

Test plan

export OPERATOR_RELEASE_VERSION=1.0.1
export OPERATOR_RELEASE_COMMENT=true # or unset it to not comment
export OPERATOR_RELEASE_ISSUE_ID=_REPLACE_ME_
export OPERATOR_RELEASE_PROJECT_ID=_REPLACE_ME_
export OPERATOR_RELEASE_TOKEN=_REPLACE_ME_
export KUBECONFIG=_PATH_TO_KUBECONFIG_OCP_4_14_

scripts/release_validate.sh

You should see console outputs, and comment on the release issue.

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.

Related issues

#1261