Independent feature gates for service config, log sinks, and auth providers

[javuto]

Independent feature gates for service config, log sinks, and auth providers

Problem

Log sinks and auth providers route registration was nested inside the
if serviceConfigEnabled block, making --service-config-enabled a
master gate. An operator who wanted log sinks or auth providers
accessible without exposing the service-config management UI had no
way to do it — enabling service config was a prerequisite for the other
two.

Solution

Decouple all three features into fully independent gates. Each has its
own flag, env var, handler field, and route registration block. No
feature requires another to be enabled.

Changes

Config (pkg/config/types.go, pkg/config/flags.go)

Two new *bool fields on YAMLConfigurationService:

Field	Flag	Env var	Default (nil → true)
LogSinksEnabled	--log-sinks-enabled	LOG_SINKS_ENABLED	true
AuthProvidersEnabled	--auth-providers-enabled	AUTH_PROVIDERS_ENABLED	true

ServiceConfigEnabled remains a plain bool (default false,
unchanged). The new fields are *bool so nil means "default to true"
— existing deployments that only set SERVICE_CONFIG_ENABLED=true get
all three enabled without any config changes.

Flag help text updated to say "Independent of --service-config-enabled"
instead of "Only takes effect when --service-config-enabled is also true".

Handlers (cmd/api/handlers/handlers.go, features.go)

• HandlersApi gained LogSinksEnabled bool and
  AuthProvidersEnabled bool fields.
• New WithLogSinksEnabled(bool) and WithAuthProvidersEnabled(bool)
  options.
• FeaturesResponse now reports each flag independently:
  LogSinks: h.LogSinksEnabled, AuthProviders: h.AuthProvidersEnabled
  — no && h.ServiceConfigEnabled condition.

Route registration (cmd/api/main.go)

• The restartLimiter / restartRateLimit definition moved out of the
  service-config if block to the top level, so all three apply
  endpoints can share it regardless of which features are enabled.
• Three independent if blocks:
  • if flagParams.Service.ServiceConfigEnabled { ... } — service-config routes only.
  • if logSinksEnabled { ... } — log-sinks routes only.
  • if authProvidersEnabled { ... } — auth-providers routes only.
• Log messages updated: each disabled feature logs independently
  without conditioning on ServiceConfigEnabled.

Defaults and backwards compatibility

Scenario	Before	After
SERVICE_CONFIG_ENABLED=true (no other flags)	All three enabled	All three enabled (new flags default to true)
SERVICE_CONFIG_ENABLED=false (no other flags)	All three disabled	Log sinks + auth providers enabled (new defaults), service config disabled
--service-config-enabled=false --log-sinks-enabled=false	N/A	Log sinks disabled, auth providers enabled, service config disabled
--service-config-enabled=false --auth-providers-enabled=false	N/A	Auth providers disabled, log sinks enabled, service config disabled

The key change: an operator can now run with
--service-config-enabled=false and still manage log sinks and auth
providers from the UI — the service-config section is simply hidden.

Validation

• Go: 45 packages pass, 0 failures.
• Frontend: 242 tests pass, type check clean.

Files

Modified (5 files):

• pkg/config/types.go — LogSinksEnabled *bool, AuthProvidersEnabled *bool fields
• pkg/config/flags.go — --log-sinks-enabled, --auth-providers-enabled flags
• cmd/api/handlers/handlers.go — LogSinksEnabled, AuthProvidersEnabled fields + options
• cmd/api/handlers/features.go — independent feature reporting
• cmd/api/handlers/features_test.go — updated test to set all three flags
• cmd/api/main.go — independent if blocks, moved restartLimiter to top level