[TASK] Config: give each service its own dedicated config file and remove env-var dependency

[Aravinda-HWK]

What needs to be done?

Summary

Raven ships four services — server, sasl, delivery, socketmap (cmd/) — but configuration is currently inconsistent: three different loaders, a --config flag that is silently ignored by two services, one service configured entirely through environment variables, and no per-service config files.

Goal: every service should load its configuration from its own dedicated config file, honored via --config, with no environment variables required.

---

Current State

Service	Loader	--config flag	Source of truth
server	conf.LoadConfig()	yes, but ignored	hardcoded path search (config.go:46-50) + env vars
sasl	conf.LoadConfig()	yes, but ignored	hardcoded path search + env vars
delivery	config.LoadConfig(path)	yes (honored)	/etc/raven/delivery.yaml + DefaultConfig()
socketmap	config.Load()	none	environment variables only (config.go:20-27)

Only config/raven.yaml and config/delivery.yaml exist today; server and sasl share raven.yaml, and socketmap has no file at all.

---

Problems

1. Dead --config flag (bug). cmd/server and cmd/sasl pass --config, but conf.LoadConfig() takes no path and searches a hardcoded list — the flag has no effect.

2. No per-service config files. server/sasl share one file; socketmap has none.

3. Environment variables are required. Configuration is currently spread across env vars instead of files:

• socketmap: SOCKETMAP_HOST, SOCKETMAP_PORT, THUNDER_HOST, THUNDER_PORT, CACHE_TTL_SECONDS, TOKEN_REFRESH_SECONDS
• server/sasl (via internal/conf): THUNDER_DEVELOP_APP_ID, APPLICATION_ID, applicationId, IDP_FLOW_ACTION, IDP_SYSTEM_USERNAME, IDP_SYSTEM_PASSWORD

4. Three separate config implementations (internal/conf, internal/delivery/config, internal/socketmap/config) with inconsistent defaults and error handling.

---

Desired End State

Each service loads one dedicated config file:

config/server.yaml
config/sasl.yaml
config/delivery.yaml
config/socketmap.yaml

• Each service exposes a working --config <path> flag that points to its own file (sane default under /etc/raven/<service>.yaml).
• No environment variables are required — every setting currently read from env (listed above) is moved into the appropriate service's config file.
• Each config file is fully self-describing, with a checked-in example and documentation in docs/.

---

Proposed Direction

• Define a per-service config schema (struct + YAML) for each of the four services.
• Consolidate loading into a shared helper in internal/conf that accepts an explicit path from --config and applies code defaults — used by all four services (each with its own schema).
• Fix server/sasl so --config is actually honored (resolves problem 1).
• Add a --config flag to socketmap.
• Move all env-var settings into the corresponding config files and remove the os.Getenv lookups in non-test code.
• Add example files config/server.yaml, config/sasl.yaml, config/socketmap.yaml (and keep config/delivery.yaml); deprecate/split config/raven.yaml.
• Document each service's config in docs/.

---

Acceptance Criteria

• Each service starts solely from its own config file via --config, with no env vars set.
• --config <path> is honored by all four services.
• No os.Getenv calls remain in service configuration code paths (non-test).
• Example config file and docs exist for every service.

---

Notes / Best Practices Applied

• One config file per deployable service — clear ownership, independent deployment.
• Explicit --config path over implicit path-search magic — reproducible, testable.
• Config-as-files over scattered env vars — auditable, versionable, no hidden runtime state; precedence kept simple: --config file → code defaults.