Allow Hadoop configuration mounts in API pods

Added `api.extraVolumes` and `api.extraVolumeMounts` using the chart's existing Worker pattern, with empty defaults and generated documentation.

apache/dolphinscheduler · #18639

Deployment configuration improvement

DolphinScheduler API and Worker pods can consistently receive ConfigMap-backed Hadoop XML settings through the Helm chart.

Problem

The chart documented copying `core-site.xml` and `hdfs-site.xml` for HDFS HA, but API workloads could not consume equivalent configurable mounts even though Worker workloads could.

Approach

Renders opt-in API volumes and mounts, documents read-only individual XML mounts and image-specific paths, and explains that pods must restart after ConfigMap updates. Existing default workloads remain unchanged.

Impact and scope

Lets operators supply the same Hadoop client configuration to both API and Worker components from existing ConfigMaps.
Supports chart-level configuration for already provisioned HDFS deployments without baking environment-specific XML into images.
Adds no incompatible default behavior because both new values default to empty lists.

Validation

Strict Helm 3 lint/rendering passed with pinned dependencies, and Kubernetes 1.31 schema validation accepted 29 generated resources.
Pinned API and Worker image probes loaded mounted Hadoop XML settings; negative controls failed without the mounts. Disabled components emitted no workloads and default manifests were unchanged.
GitHub build, Helm docs, Kubernetes E2E, API, unit, CodeQL, and broad integration checks passed. A dead-link check failed separately; the verified merge commit credits Goutam Adwant.
Validation was local and CI-based. No live Kubernetes deployment, HDFS resource operations, failover, or Kerberos flow was tested; the existing common-properties mount-path discrepancy remains outside this change.