chore: deploy custom dspa cert

[HumairAK]

When a configmap trust ca store is provided, whether it's from a user provisioned configmap with a ca bundle via the DSPA's caBundle field, or whether it's a configmap name "odh-trusted-ca-bundle" (provided by odh or user), then this change will create an amalgmation of all of the certs from these configmaps and create a single dspo managed configmap. The resulting configmap has a single cert that is the accumulation of all afore mentioned certs, and can be passed as a single file to the dsp server, or pipeline pods to utilize.

This helps work around issues and overhead work required when mounting to a ca path with multiple certs, because such a path requires that it first be re_hashed. Furthermore this allows us to work around issues related to aws cli being unable to utilize ca paths with it's AWS_CA_BUNDLE env variable when passing artifacts during the step-copy-artifacts step.

The issue resolved by this Pull Request:

Related: https://issues.redhat.com/browse/RHOAIENG-1690

Testing instructions

• have a minio/mariadb that are tls enabled serving self-signed certs
• in a test namespace provide configmap that has the root CAs to recognize these certs
  • the configmap can be named "odh-trusted-ca-bundle", in which case dspo will automatically use it
  • the configmap can be named something else, but then the configmap name, and key (pointing to the cert) should be provided in the DSPA
  • you can also use both methods together (e.g. if mariadb cert is provided via odh-trusted-ca-bundle, while minio is provided via dspa), both will work
• deploy dspa with external connections to tls enabled minio/mariadb, point the ca bundle in dspa if needed based on above

Checklist

• The commits are squashed in a cohesive manner and have meaningful messages.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work

[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 humairak. 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

[dsp-developers]

A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-579
An OCP cluster where you are logged in as cluster admin is required.

To use this image run the following:

cd $(mktemp -d)
git clone git@github.com:opendatahub-io/data-science-pipelines-operator.git
cd data-science-pipelines-operator/
git fetch origin pull/579/head
git checkout -b pullrequest 1dd2a20ab91354126552bf777334a9f9b4d4a6cb
oc new-project opendatahub
make deploy IMG="quay.io/opendatahub/data-science-pipelines-operator:pr-579"

More instructions here on how to deploy and test a Data Science Pipelines Application.

[dsp-developers]

Change to PR detected. A new PR build was completed.
A new image has been built to help with testing out this PR: quay.io/opendatahub/data-science-pipelines-operator:pr-579