Add Config to FlagConfig struct

[peppi-lotta]

This refactoring allows the Serve function to be called without requiring a YAML configuration file. As a result, the function becomes easier to use from other projects, since configuration is no longer tied to an external YAML file.

The change was proposed in PR #7255 to the CoreDNS project. To maintain backward compatibility while enabling this flexibility, I added a Config field to the FlagConfig struct. This approach preserves the existing behavior while allowing external projects to inject configuration directly.

[peppi-lotta]

@SuperQ Here's my proposed change to enhance FlagConfig so it can accept either a config file path or a Config object. This change maintains existing functionality, but makes the code easier to integrate from other codebases.

Let me know if this aligns with your vision for the refactor. I'm happy to adjust the implementation in any way if needed.

[kashifest]

@SuperQ can we have some review on this? It would be good to get this one rolling

[mrueg]

Thanks for the PR! As right now this is either config struct or file based, do we see a use case where an app wants to set certain defaults via the config struct and have the user overwrite it via the file?

[SuperQ]

I think the either config or file is fine. We don't need a combo.

[peppi-lotta]

@mrueg I have now added a function for validating the config. Could you please take a look and provide a review when you have a chance?

[nuhakala]

@mrueg Could we get a review on this?

[peppi-lotta]

@mrueg @SuperQ Please let me know if there is something I can do to move this forward :)

[peppi-lotta]

@mrueg @SuperQ Please review these changes or let me know who I can ping for review :)

[peppi-lotta]

@ArthurSens @mrueg @SuperQ This has been on hiatus for a while but I feel this is still a good addition. PTAL :)

[ArthurSens]

/approve-workflow

[ArthurSens]

I'm not sure if we want WebConfig to override WebConfigFile. I'm happy for them to be mutually exclusive, then downstream projects using exporter-toolkit can implement the overriding logic by themselves. My worry is that today WebConfigFile is the only way of doing this, if the new WebConfig overrides the current behavior, that's a breaking behavior. Feels safer to not do the override 🤔

[peppi-lotta]

I'm not sure if we want WebConfig to override WebConfigFile. I'm happy for them to be mutually exclusive, then downstream projects using exporter-toolkit can implement the overriding logic by themselves. My worry is that today WebConfigFile is the only way of doing this, if the new WebConfig overrides the current behavior, that's a breaking behavior. Feels safer to not do the override 🤔

I've now made WebConfig to override WebConfigFile mutually exclusive. If both are set there will be a "conflicting flags" error. I've added necessary unit testing for this as well.