Support enabling EPP feature gates without duplicating the full plugin config

[LukeAVanDrie]

What would you like to be added:

A way to enable an EPP feature gate (for example flowControl) on top of an existing plugin configuration without copying the entire EndpointPickerConfig document. This issue proposes (a), a --feature-gates flag, as the primary direction, and (b), structured plugin config in the chart, as a complementary chart-side option.

(a) A --feature-gates EPP flag

Kubelet-style: --feature-gates=flowControl=true.

• loadFeatureConfig (pkg/epp/config/loader/configloader.go) parses kubelet-style name=bool entries and defaults bare names to true. The flag can feed the same parser.
• Later featureGates entries override earlier ones. Appending flag-supplied entries to rawConfig.FeatureGates in Runner.parseConfigurationPhaseOne (cmd/epp/runner/runner.go), after the config file is read, makes flag entries win over file entries.
• The flag definition belongs in pkg/epp/server/options.go, alongside --config-file.
• No chart change is needed for Helm delivery: routerlib renders arbitrary EPP flags from router.epp.flags.

(b) Structured plugin config in the chart

Add router.epp.pluginsConfig (a structured map) to routerlib, rendered with toYaml into the ConfigMap (config/charts/routerlib/templates/_config.yaml) alongside the existing pluginsCustomConfig. Helm deep-merges maps across -f files, so an overlay can set featureGates: [flowControl] and inherit plugins and schedulingProfiles from an earlier values file. Limits: Helm replaces lists as a unit, so plugins cannot be merged per-entry; YAML comments are lost in the toYaml round trip; non-Helm deployments are unaffected.

Why is this needed:

Enabling a feature gate requires owning the whole config document via pluginsCustomConfig, which the chart splices into the ConfigMap as a single string. Every llm-d guide that enables flowControl carries a full copy of the optimized-baseline plugin list, and the copies drift: the keda-epp-queue guide's copy no longer matches optimized-baseline's plugin set, and llm-d/llm-d#2248 tracks a guide that broke while working around this gap. Reviewers on llm-d/llm-d#2229 asked for an overlay that adds only the gate. Helm values layering cannot produce one, because layering replaces string values and the whole config is one string.

[LukeAVanDrie]

If we want to do both (a) and (b), this work can be parallelized. I think (a) is probably the better place to start.

[LukeAVanDrie]

FYI for (a), parseConfigurationPhaseOne caches its result and is called twice, and there's a file-discovery/reload path (runWithFileDiscovery). Any flag-supplied gates need to survive config reloads, not just initial load.

[abhishekkarki]

I would like to take (a) @LukeAVanDrie
/assign

[hugosmoreira]

I can take option (b), adding structured pluginsConfig rendering and focused Helm tests, while @abhishekkarki handles the feature-gates flag.

[abhishekkarki]

@LukeAVanDrie branch is up, PR coming shortly. Approach: --feature-gates as a StringSliceVar in options.go, threaded into LoadRawConfig via a variadic param and appended to rawConfig.FeatureGates before validateFeatureGates - so flag entries win over file entries and get the same validation.

Re: the cache/reload note - appending to the struct rather than the returned map covers it, since InstantiateAndConfigure and validateConfig both re-derive gates from rawConfig.FeatureGates. runWithFileDiscovery gets its config from the same call, and there's a test for the double call.

Flag name and flag-over-file precedence sound right?