Support loading network configuration from file

[apoorvdarshan]

Summary

• Adds --config option to container-network-vmnet start that accepts a path to a JSON configuration file, closing [Request]: Support loading network configuration from file #1047
• Introduces NetworkConfigurationFile as an intermediate Codable struct that is decoded from JSON and converted to a full NetworkConfiguration via toNetworkConfiguration(id:)
• CLI flags override config file values when both are provided (not mutually exclusive)
• --mode and --variant changed to optionals so explicit CLI usage can be detected and preferred over config file values

Test plan

• Added unit tests for NetworkConfigurationFile: minimal decode, complete decode, invalid subnet, invalid ID
• All existing NetworkConfigurationTest tests continue to pass
• swift build succeeds
• swift test --filter NetworkConfigurationTest passes (9/9 tests)

[jglogan]

@apoorvdarshan Thank you for the contribution!

@katiewasnothere Was the --config option in #1047 meant for container network create or for container-network-vmnet start? I thought it was for the latter.

[katiewasnothere]

@jglogan #1047 is for adding --config as an option on container-network-vmnet start

[saehejkang]

I was drafting this comment when I noticed things were changing a bit. However, I believe the feedback is still valid and may be worth discussing.

---

Instead of making the flags mutually exclusive, I think we should check whether a CLI option is explicitly set and prefer it over the value from the config file when both are provided (intentionally or accidentally)? It seems to be a more common and flexible pattern that improves usability.

[apoorvdarshan]

Thanks for the feedback!

@katiewasnothere Good catch — I've moved the --config option from container network create to container-network-vmnet start as intended by #1047.

@saehejkang Agreed, the override approach is better. I've updated the implementation so that CLI flags override config file values when both are provided, rather than making them mutually exclusive. --mode and --variant are now optionals so we can detect when they're explicitly set vs defaulted.

[jglogan]

@apoorvdarshan Thanks! I think we'll need until a little later next week to work through some design stuff related to this. We may need a change or two but what you have is in the direction of where things are going.

On these helper executables, we're wanting to eliminate the options in favor of either a --config option or maybe a --path option to an entity directory (like the container bundle directory), and then the config would be at a conventional path inside.

This helps make it so that the plugin-specific details of runtimes and networks are the concern of the CLI and service plugins, and those details are opaque to the containers and networks services in the API server; they just need to create the entity directories that the plugins understand.

[apoorvdarshan]

@jglogan Thanks for the context! That makes sense — having helper executables take a --config or --path option instead of individual flags keeps plugin-specific details out of the API server. Happy to iterate on this once the design is finalized next week.