Improved extension handling

[fhennig]

As a user I want to know when which extensions get loaded by default and also how I can configure additional extensions to load. Loading more extensions should be easy.

Improve loading extensions

Currently you have to use a configOverride to load a new extension. This is error prone, because you have to not only specify your additional extension, but also all the other extensions that are configured by the operator. This could either be a simple list of strings to add, or a map with the option to have configuration settings for the extensions in there.

CRD Change

We propose the following change to the DruidCluster CRD:

---
kind: DruidCluster
spec:
  clusterConfig:
    additionalExtensions:
    - druid-avro-extensions
    - druid-bloom-filter

Only a list of extensions to load can be specified to keep the CRD as simple and clean as possible.

Many extensions that require additional configuration are already being loaded conditionally based on other parts of the CRD, e.g. authentication, deep storage or metadata storage. If in some cases this is not enough (e.g. because we haven't added an option for deep storage yet) the extension can still be loaded by adding it to the additionalExtensions list with the extension-specific configuration being added using configOverrides.

Document which extensions are loaded by default

We load some extensions conditionally, such as the google or HDFS extensions or the pac4j extension for OIDC support. We should document when which extension gets loaded. Also the list of the default extensions that we load. Maybe also add a link to the Druid documentation where possible extensions are listed.

### Tasks
- [ ] <Implementation PR>
- [ ] https://github.com/stackabletech/druid-operator/issues/487

[sbernauer]

I would like to point out again that IMHO we should allow extension-specific properties. Just collecting my messages condensed below:

Looking at e.g. github.com/orgs/stackabletech/discussions/15 I think we might want to add dedicated extensions in the future - in this case for google cloud extensions with bucket name and credentials secret.

Have not spend many thoughts on this, my only requirement is that we can add properties to extensions. Does not need to be right now, just give us the chance to add that non-breaking. For avro specifically I don't see a reason to not always enable it.
CRD could look something like

kind: DruidCluster
spec:
  clusterConfig:
    additionalExtensions:
      druid-google-extensions: # optional
        enabled: true # defaults to false
        credentialsSecret: my-google-credentials # mandatory, gets put into GOOGLE_APPLICATION_CREDENTIALS
        bucket: my-bucket # mandatory
        prefix: / # mandatory, defaults to /
        maxListingLength: 1024 # optional
      druid-avro-extensions: # optional
        enabled: true # defaults to false
      # All extensions that we don't enumerate explicitly can be loaded here 
      customExtensions:
        - druid-avro-extensions
        - druid-bloom-filter
        - gce-extensions

As a first step we could simply add all extensions that don't need any configuration options (such as avro)

[labrenbe]

Moving to voting.

[razvan]

I didn't comment while it was on RfC, so feel free to ignore this.

I would much prefer an explicit solution that doesn't differentiate between additionalExtensions and customExtensions but provides an orthogonal interface (i.e. a list) as most users don't care about the Rust implementation, and this complicates the CRD unnecessarily for them.