Adds functionality to specify custom catalog definitions for Trino.

[soenkeliebau]

Description

Trino requires catalog definitions to be defined in files, not dynamically via the api.
We currently do not support adding extra catalogs that are not provided by the Trino operator (which is only Hive at the moment).

This PR adds a 'customCatalogs' property which allows specifying arbitraty ConfigMaps to pull in for catalog definitions.

Review Checklist

• Code contains useful comments
• (Integration-)Test cases added (or not applicable)
• Documentation added (or not applicable)
• Changelog updated (or not applicable)
• Cargo.toml only contains references to git tags (not specific commits or branches)
• Helm chart can be installed and deployed operator works (or not applicable)

Once the review is done, comment bors r+ (or bors merge) to merge. Further information

[soenkeliebau]

This PR was mostly to get Rob something to work with for his first iteration of the demo and enable adding catalogs to Trino at all.

Before merging this we should discuss how we want this to look in the CRD and how we might want to enable making it variable across environments.
For example deploying the same Trino object to two clusters with no changes, which in turn then connects to different databases (dev / test).

Proposal (doesn't meet what I wrote above yet):

---
apiVersion: trino.stackable.tech/v1alpha1
kind: TrinoCluster
metadata:
  name: simple-trino
spec:
  ...
  catalogDefinitions:
    - hive: 
        cluster-name: simple-hive
    - s3:
        endPoint: changeme
        accessKey: changeme
        secretKey: changeme
        sslEnabled: false
        pathStyleAccess: true
     - custom:
         configMapName: custom-1
     - custom:
         configMapName: custom-2
  ...

[sbernauer]

I'm not sure whats the current state here but I'm just throwing in the possibility of making a Catalog CRD. Especially since they Catalogs are quite complicated and e.g. a Hive or Iceberg catalog need a S3Connection (see discussion yesterday stackabletech/documentation#177) or an kerberos auth method (we may need secret operator), also a hdfs-site.xml. I think it's the same as with S3 and we need a CRD, ConfigMaps are not flexible enough.

Anyhow i would try to prevent the same communication thing happening as with S3 definition and propose an official ADR for this :)

[soenkeliebau]

We have agreed that this shouldn't be part of the TrinoCluster CRD itself. There is no currently active design effort around this I believe though ..

[sbernauer]

Just for the record: We designed the Trino CRDs in ADR 19 + 20
https://docs.stackable.tech/home/contributor/adr/ADR019-trino_catalog_definitions.html
https://docs.stackable.tech/home/contributor/adr/ADR020-trino_catalog_usage.html

[sbernauer]

@soenkeliebau can we close this in favor of WIP #209?

[soenkeliebau]

Absolutely!