Allow easily disabling unused components in self-hosted OneUptime

[sajad-sadra]

Is your feature request related to a problem? Please describe.
When self-hosting OneUptime I (and many other operators) see a lot of bundled components/services that are not needed for every deployment. This increases resource usage, operational complexity, upgrade surface, and the attack surface. Right now the only practical ways to remove them are manual edits to manifests/docker-compose or forking the repo — both error prone and hard to maintain.

Describe the solution you'd like
Provide a first-class way to opt out of individual components at install/upgrade time and at runtime. Examples of ways to implement this (not prescriptive—any approach that works is fine):

• Helm values / installer flags to enable/disable services (so unwanted pods are not created and related migrations are skipped).
• Environment variables / docker-compose toggles for single-host installs.

Describe alternatives you've considered
I tried removing some components in from the docker-compose but the ingress config is immutable and it broke down because of this.

Additional context
Benefits: reduced memory/CPU and storage usage, smaller attack surface, faster upgrades, simpler debugging for small deployments, and better suitability for resource-constrained environments.
Examples of components users might want to opt out of: analytics/telemetry workers, optional integrations, bundled object storage, or secondary monitoring components — these are only examples; the request is for a general per-component opt-out mechanism.

If helpful, I can contribute a PR that wires Helm values into manifests or a sample docker-compose pattern showing enabled: true|false semantics.