docs(rfc): add gateway configuration file RFC

[TaylorMutch]

Summary

Adds RFC 0002 proposing a TOML-based configuration file for the OpenShell gateway. The RFC defines the file schema, merge precedence (CLI > env > file > defaults), driver-specific config sections, validation rules, and backwards compatibility guarantees. It also outlines the remaining implementation work and the Helm integration path.

Related Issue

Changes

• Added rfc/0002-gateway-configuration/README.md with the full RFC

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[mrunalp]

👍 to this. Another thing to consider is adding a conf.d folder where config sections could be dropped in. We have adopted similar patterns in cri-o and kubelet inspired by systemd.

[TaylorMutch]

Great call-out, @mrunalp — this is exactly what open question #2 in the RFC is gesturing at.

A conf.d-style directory loader is a clean v2 on top of the single-file approach: glob *.toml files in sorted order, deep-merge them, then let CLI/env still win at the top. The Kubernetes case maps perfectly: base settings from a ConfigMap, driver config from a second ConfigMap, and credentials from a projected Secret volume — all mounted into the same directory as separate files without needing a monolithic config.

Key design decisions we'd need to nail down before implementing:

• --config vs --config-dir: mutually exclusive or composable (and if composable, which takes lower precedence)?
• Array semantics: does a later file's compute_drivers replace or append? Replace is simpler and less surprising.
• Validation: deny_unknown_fields needs to apply to the final merged result, not each individual file, since partial drop-ins won't have all sections.

Planning to update the RFC to close out question #2 with this direction and mark the directory loader as a planned follow-on. The single --config file stays as v1 scope.