Publish OCI Helm charts for all OSOK service packages

[HaoyL666]

Summary

Provide a supported, generated Helm OCI chart for every publishable OCI Service Operator service package. Users should be able to install any service controller directly from GHCR with Helm, without requiring Operator SDK or OLM.

This is related to #29, but tracks a concrete multi-service OCI Helm packaging and release path rather than only a single installer manifest.

A PostgreSQL-only pilot demonstrated the packaging approach, but the production design should be generic and driven by the existing service-package metadata instead of containing service-specific chart generation logic.

Proposed behavior

For each service returned by the package source of truth, generate and publish a chart using a consistent reference such as:

oci://ghcr.io/oracle/oci-service-operator-<service>-chart

The chart version and default controller image must be produced from the same OSOK release. helm install --version selects the chart version; chart defaults select the matching controller image. Users may override the image repository, tag, or immutable digest through values.

The existing OLM bundles remain supported and unchanged.

Requirements

• Generate charts from the same CRD, RBAC, manager deployment, and package metadata used by the existing per-service package pipeline.
• Avoid handwritten copies of service manifests and avoid service-specific branching in the generic chart builder.
• Publish one immutable OCI chart per service and release version to GHCR.
• Use the Helm release namespace; do not create a Namespace object in a chart.
• Reference an existing OCI credentials Secret. Never place credential values in chart values or rendered release metadata.
• Support common controller configuration through validated values, including:
  • image repository, tag, digest, and pull policy
  • existing credentials Secret and authentication type
  • service account annotations
  • pod and container security contexts
  • resources, scheduling, labels, and annotations
  • proxy and custom CA configuration
  • leader election and manager endpoints where supported
• Preserve least-privilege RBAC and restricted Pod Security compatibility.
• Install CRDs on first install and document the explicit CRD apply step required before upgrades.
• Retain CRDs and custom resources on uninstall so uninstall cannot silently delete managed OCI resources.
• Support GitOps installation from Argo CD using an OCI Helm source and valuesObject, including a controller image digest-pinning example.
• Refuse to overwrite an existing chart version and expose the resulting OCI chart digest and checksums in release output.
• Document install, upgrade, rollback, uninstall, image override, authentication, and CRD lifecycle behavior.

Acceptance criteria

• Every publishable OSOK service package has a generated Helm chart and a documented GHCR OCI reference.
• The chart release version and default controller image release match for every service.
• A common values schema validates supported configuration and rejects invalid or unknown values.
• CI runs chart generation, schema validation, strict helm lint, security checks, and parity checks against the package manifests for every service.
• CI validates install, upgrade, and uninstall behavior for generated charts, including CRD retention and controller readiness.
• The publishing workflow builds multi-architecture controller images before publishing the matching immutable charts.
• A release smoke test installs representative service charts from GHCR and verifies controller startup plus basic custom-resource reconciliation.
• Public installation documentation explains both Helm and OLM paths and their lifecycle differences.

[HaoyL666]

jira: https://jira.oci.oraclecorp.com/browse/OKE-44460