[1.2.x] ci: Fix image repo location when pushing operator images

[rm3l]

Description

The nightly Workflow passes but with a warning on 1.2.x about a missing quay.io/rhdh-community/operator:0.2.3 image tag. Example: https://github.com/redhat-developer/rhdh-operator/actions/runs/10624194874

These warnings can be expected since CI tags purposely expire after a few weeks. But in this specific case, we should have recent image builds from the 1.2.x branch because that branch has been updated recently.
It looks like the job building and pushing that image on 1.2.x did not pass: https://github.com/redhat-developer/rhdh-operator/actions/runs/10620716428/job/29441095997

Successfully tagged quay.io/rhdh-community/operator-catalog:0.2.3
28bce337c49efa5435c24f607dad615f4bd0ffa4f026175b896dc81ce0e43749
+ for image in operator operator-bundle operator-catalog
+ podman push quay.io/janus-idp/operator:0.2.3 -q
Error: quay.io/janus-idp/operator:0.2.3: image not known

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

• Fixes issues with the image building workflow: https://github.com/redhat-developer/rhdh-operator/actions/runs/10620716428/job/29441095997
• Fixes https://issues.redhat.com/browse/RHIDP-3704

PR acceptance criteria

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

How to test changes / Special notes to the reviewer

—

/cc @nickboldt

[github-actions]

PR images are available:

1. https://quay.io/rhdh-community/operator:0.2.3-pr-124-bb64b76
2. https://quay.io/rhdh-community/operator-bundle:0.2.3-pr-124-bb64b76
3. https://quay.io/rhdh-community/operator-catalog:0.2.3-pr-124-bb64b76

[nickboldt]

LGTM but did you check if other actions or scripts (like the makefile) are also still using janus-idp instead of rhdh-community ?

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gazarenkov, nickboldt

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [gazarenkov,nickboldt]

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

[rm3l]

LGTM but did you check if other actions or scripts (like the makefile) are also still using janus-idp instead of rhdh-community ?

Yes, I checked that, and it should be fine. These are the remaining occurrences of janus-idp in this PR branch:
The on-new-issue.yaml file could be deleted, since GH issues are disabled in this repo.

.github/README.workflows.adoc:* link:https://github.com/openshift/release/tree/master/core-services/prow/02_config/janus-idp/[core-services/prow/02_config/janus-idp/]
.github/workflows/on-new-issue.yaml:    # https://github.com/janus-idp/.github/blob/main/.github/workflows/add-to-project.yaml
.github/workflows/on-new-issue.yaml:    uses: janus-idp/.github/.github/workflows/add-to-project.yaml@main
README.md:The initial target is in support of Red Hat's assemblies of Backstage - specifically supporting [dynamic-plugins](https://github.com/janus-idp/backstage-showcase/blob/main/showcase-docs/dynamic-plugins.md) on OpenShift. This includes [Red Hat Developer Hub (RHDH)](https://developers.redhat.com/rhdh) but may be flexible enough to install any compatible Backstage instance on Kubernetes. See additional information under [Configuration](docs/configuration.md).
README.md:The telemetry data collection feature is enabled by default. The default configuration uses image with backstage-plugin-analytics-provider-segment plugin enabled and configured. To disable this and to learn what data is being collected, see https://github.com/janus-idp/backstage-showcase/blob/main/showcase-docs/getting-started.md#telemetry-collection 
bundle/manifests/backstage-default-config_v1_configmap.yaml:      # generated with the command below (from https://janus-idp.io/docs/auth/service-to-service-auth/#setup):
config/manager/default-config/secret-envs.yaml:  # generated with the command below (from https://janus-idp.io/docs/auth/service-to-service-auth/#setup):
docs/configuration.md:  The Operator can configure [Dynamic Plugins](https://github.com/janus-idp/backstage-showcase/blob/main/showcase-docs/dynamic-plugins.md). To support Dynamic Plugins, the Backstage deployment should contain a dedicated initContainer called **install-dynamic-plugins** (see [RHDH deployment.yaml](../config/manager/default-config/deployment.yaml)). To enable the Operator to configure Dynamic Plugins for a specific Backstage instance (CR), the user must create a ConfigMap with an entry called **dynamic-plugins.yaml**.
examples/showcase-config.yaml:               image: quay.io/janus-idp/backstage-showcase
pkg/model/dynamic-plugins.go:           // TODO workaround for the (janus-idp, rhdh) case where we have
tests/e2e/e2e_test.go:                                                  ContainSubstring("@janus-idp/backstage-scaffolder-backend-module-quay-dynamic"),
tests/e2e/e2e_test.go:                                                  ContainSubstring("@janus-idp/backstage-scaffolder-backend-module-regex-dynamic"),