[Feature]: Configuration management refactoring

[daohu527]

Use Case / Motivation

1. The current configuration does not consider parameter services.
2. Using symbolic links to override existing configurations will pollute the default settings.

Proposed Implementation

Epic: Refactor Apollo Configuration Management (Layered Override Support)

🧠 Background

Apollo’s configuration system currently loads config files directly with no hierarchical override support. This leads to difficulties in managing environment-specific config, persistent overrides, and live parameters from a central parameter server.

The refactor should introduce layered config overrides with controlled merge logic and security.

---

🎯 Goals

Create a reusable configuration loader that:

1. Loads defaults from source
2. Applies overrides from /data/conf/
3. Merges with Parameter Server values as the highest priority

Additionally, ensure sensitive fields are not stored in defaults and document everything clearly.

---

📋 Sub-Tasks

1. Configuration Scan and Inventory

Objective:

• Scan the codebase for all config loading points
• Identify modules, file types, and loader functions

Deliverables:

• JSON table or Markdown mapping file path → loader → module

---

2. Define Layered Override Logic

Objective:

• Write a spec for merge priority:

  1. Defaults (lowest priority)
  2. External persistent overrides
  3. Parameter Server (highest priority)

Deliverables:

• Design doc in Markdown

---

3. Implement Protobuf Deep Merge

Objective:

• Write a merge utility for Protobuf messages using deep merge (not simple overwrite)

Deliverables:

• C++ merge function
• Example usage

---

4. Update Config Loaders

Objective:

• Modify modules to use layered override logic in loading configs

Deliverables:

• Refactored loader implementations

---

5. Secure Sensitive Fields

Objective:

• Remove any sensitive tokens / keys from source defaults
• Store secrets only in /data/conf

Deliverables:

• Updated proto defs
• Documentation

---

6. Documentation

Objective:

• Document how the new override system works
• Include usage, override order, and security guidelines

Deliverables:

• Markdown under /docs/

---

🎯 Acceptance Criteria

• ✓ All config sources are inventoried
• ✓ Merge logic implemented and tested
• ✓ Overrides applied in correct order
• ✓ Sensitive info omitted from defaults
• ✓ Documentation exists and is clear

Alternatives Considered

No response