Analyze a flat heterogeneous service configuration

[josecelano]

Part of EPIC: #1978 - Configuration Overhaul (schema v3.0.0)

Goal

Determine whether a future, post-v3 configuration schema should represent all listener and service instances in one ordered heterogeneous services collection instead of separate http_trackers, udp_trackers, http_api, and health_check_api sections.

Decision Requested

Produce an evidence-based recommendation to reject the change, defer it, or create a separate implementation issue. This is non-blocking research only: it must not delay v3.0.0 delivery, #1980, or the prerequisite secrets work in #1490.

Scope

In scope

• Compare viable TOML and Rust representations, including an adjacent-tagged enum with nested per-service configuration.
• Prototype parsing, serialization, defaults, Figment environment overrides, unknown-kind errors, and singleton validation without changing production behavior.
• Analyze a normalization model that preserves existing role-specific container construction, startup dependencies, registration, metrics, and health-check behavior.
• Preserve the existing role-qualified, role-local ConfigurationInstanceId strategy as a constraint; do not evaluate alternative identifier schemes.
• Analyze migration ordering, schema-version transition policy, shared UDP policy, configuration logging and secret redaction, compatibility impacts, and implementation cost.

Out of scope

• Implementing a successor schema, loader, migration tool, normalizer, or production runtime changes.
• Changing ConfigurationInstanceId, ServiceBinding, secret storage, redaction policy, listener protocols, or runtime behavior.
• Making REST API or health-check API instances multi-instance.

Deliverables

• A final decision report with one explicit recommendation and exact scope for any follow-up implementation issue.
• A reproducible evidence ledger covering source tracing, experiments, and manual reviews.
• A preserved preliminary-impressions snapshot to compare against the final evidence.

Acceptance Criteria

• At least two viable representations are compared with an explicit recommendation or rejection rationale.
• Feasibility is demonstrated or disproved using focused TOML, Serde, Figment, serialization, defaulting, and environment-override evidence.
• The analysis covers identity, ordering, migration, shared UDP behavior, schema lifecycle, secret redaction, and observability compatibility.
• The final recommendation is traceable to reproducible evidence and includes no production implementation.
• Relevant documentation linting and any focused prototype tests pass.

References

• Parent EPIC: Overhaul: Configuration (schema v3.0.0) #1978
• Runtime v3 consumer migration: Configuration overhaul final cleanup: remove global re-exports, migrate consumers to explicit versioned imports #1980
• Secrets and database prerequisite: Decompose v3 database configuration #1490