DM-45394: Config from a single YAML file (except secrets)

[fajpunk]

Phalanx changes are in this PR

[rra]

Ideally we should also change the flock configuration and therefore the business configuration and all of those models to also support camel-case so the entire configuration can be given in camel-case for consistency. As long as you have populate_by_name set, both snake-case and camel-case will be supported. There's some trick to getting the API documentation correct (snake-case) that I used with Nublado... oh, right, you have to make separate model classes for the loaded configuration that enable the alias generator and inherit from the API models. Unfortunately, I don't know of a way to do it other than code duplication.

I'll leave it up to you whether to do that additional work. I probably would because the inconsistency of camel-case in some parts of the configuration and snake-case elsewhere really bugs me, but that might just be a me problem. :)

[fajpunk]

Ideally we should also change the flock configuration and therefore the business configuration and all of those models to also support camel-case so the entire configuration can be given in camel-case for consistency.

oh, right, you have to make separate model classes for the loaded configuration that enable the alias generator and inherit from the API models.

This ends up touching a lot of nested models. This commit allows camelCase everywhere that's necessary to specify flocks. I'm not sure how to specify non-aliased versions of this without duplicating the field specifications on a lot of models, since alias generator model config doesn't propagate to submodels (which makes sense). It would be great if we could somehow specify in the models "use the non-aliased name for OpenAPI specs please," but to your point, I don't think there is.

I agree that a mix of styles in the app config is nasty, but I'm less put off by the inconsistent style in all of the helm values, as long as all of the app config is snake case. I can justify that in my brain as "this is directly generating a file that gets fed to the app, which is a python app, which likes snake_case, whereas everything outside of this config value is a helm value that controls templating and stuff, so it should be camelCase because that's what helm likes."

I think the options are:

1. Have everything that goes in the app config yaml be snake case and snake case only. That would also make it so that API requests and docs are snake case. This leads to the least complex app code and the least confusing API docs, but inconsistent helm value style.
2. Have all of the necessary config be compatible with either style, but don't duplicate models. This leads to slightly more complex app code, an inconsistently-styled (though correct) API and docs, and completely consistent helm values.
3. Have all of the necessary config be compatible with either style, and duplicate all of the necessary models and override all of the necessary fields. This leads to consistent styles for both the API and helm values, but is there a way to do it without so much code duplication?

[fajpunk]

Have everything that goes in the app config yaml be snake case and snake case only. That would also make it so that API requests and docs are snake case. This leads to the least complex app code and the least confusing API docs, but inconsistent helm value style.

Meh, that sorta stinks too, it leaks into the helm templates more than I thought: lsst-sqre/phalanx@85938fb

[fajpunk]

I'm going to defer the work to support camelCase for the autostart config. I agree it would be nice, but I can't immediately do it without duplicating a lot of code, and I'd like to move forward with the metrics stuff. I'm going to merge this now under the auspices of "it doesn't make it worse."