Adapt the operator CI install script to work on non OCP-clusters

[rm3l]

Description

As depicted in https://issues.redhat.com/browse/RHIDP-4994, the current script and procedure for installing CI builds of the operator are tied to OpenShift (use of ICSP/IDMS resources, leveraging the internal OCP cluster registry, ...).
To unblock https://issues.redhat.com/browse/RHIDP-4550 (testing operator CI builds on GKE), this PR adapts this script to make it work on standard Kubernetes clusters. Ultimately, we should be able to use the same script to test the operator on our other supported platforms like EKS or AKS.

Note that this requires OLM to be installed in the cluster as a prerequisite since this is what we support.

The logic to install the operator on K8s is quite similar to how we adapted the script in #369 to make it work on OCP clusters with hosted control planes (by unpacking the bundles, replacing the refs to the internal RH registries, then pushing them to the cluster registry ): it starts by deploying a registry and does essentially the same things.

NOTE (for later): the script is getting big => we might need to break it down into smaller files. This is an intentional tech debt that will be addressed later (issue TBD).

Which issue(s) does this PR fix or relate to

• Fixes https://issues.redhat.com/browse/RHIDP-4994

PR acceptance criteria

• Tests
• Documentation
• If the bundle manifests have been updated, make sure to review the rhdh-operator.clusterserviceversion.yaml file accordingly

How to test changes / Special notes to the reviewer

More details in https://github.com/rm3l/redhat-developer-hub-operator/blob/RHIDP-4994--adapt-operator-ci-script-to-work-on-non-ocp-clusters/.rhdh/docs/installing-ci-builds.adoc#prerequisites

1. Run the .rhdh/scripts/install-rhdh-catalog-source.sh script against a standard Kubernetes cluster. OLM is required.

$ .rhdh/scripts/install-rhdh-catalog-source.sh --latest --install-operator rhdh
                                                                                                                
[DEBUG] Falling back to a standard K8s cluster                                                                                                                                                 
Namespace rhdh-operator does not exist; creating it                                                                                                                                            
namespace/rhdh-operator created                                                                                                                                                                
[INFO] Using iib from image quay.io/rhdh/iib:latest-v4.16-x86_64                                                                                                                               
/tmp/tmp.6aBt4aLP6K ~/work/projects/backstage/janus-idp/operator                                                                                                                               
>>> WORKING DIR: /tmp/tmp.6aBt4aLP6K <<<                                                                                                                                                       
[INFO] Detected a Kubernetes cluster 
[...]
INFO[0007] Pushing image to local-registry.rhdh-operator.svc.cluster.local:5000/rhdh/iib:latest-v4.16-x86_64                                                                                   
INFO[0008] Pushed local-registry.rhdh-operator.svc.cluster.local:5000/rhdh/iib@sha256:c6e0e73f3cf1c2179a8bfa5f19afb1acd007f2bd047b2353e5a5900b48138c4b                                         
job.batch/kaniko-build-1732913167 condition met                                                                                                                                                
[DEBUG] IIB built and pushed to internal cluster registry: localhost:30389/rhdh/iib:latest-v4.16-x86_64...                                                                                     
[DEBUG] newIIBImage=localhost:30389/rhdh/iib:latest-v4.16-x86_64                                                                                                                               
catalogsource.operators.coreos.com/rhdh-fast created                                                                                                                                           
Creating OperatorGroup to allow all-namespaces operators to be installed                                                                                                                       
operatorgroup.operators.coreos.com/rhdh-operator-group created                                                                                                                                 
subscription.operators.coreos.com/rhdh created 
[...]

2. Create an image pull secret with your registry.redhat.io creds (this is required to pull the PostgreSQL images, which are not mirrored on Quay)

$ kubectl create secret docker-registry rhdh-pull-secret \     
    --docker-server=registry.redhat.io \
    --docker-username="$RRIO_USERNAME" \
    --docker-password="$RRIO_PASSWORD" \
    --docker-email=$EMAIL

3. Add the pull secret to the default service account in the namespace where you intend to deploy RHDH

$ kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "rhdh-pull-secret"}]}' 

4. Create your RHDH CR:

$ kubectl apply -f examples/bs1.yaml

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from rm3l. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rm3l]

/cherry-pick release-1.4

[openshift-cherrypick-robot]

@rm3l: once the present PR merges, I will cherry-pick it on top of release-1.4 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.4

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[rm3l]

/cc @zdrapela

This should help with testing downstream CI builds of the operator on non-OCP clusters.