Fullstack: refactor config storage and processing

[webecke]

As we keep adding more and more config options, the management of config state on the front end is getting more and more difficult to manage. This needs to be refactored into something thats easier to manage and more expandable.

This could involve a restructuring into different config systems, or just a simplification of how config values are processed and stored. I'll figure it out once I get started on it.

[webecke]

Potential idea: We make a ConfigDataTransferClass, and that just gets serialized when we ask for it on the front end. That way we can structure config things and nest them for sensible organization. Then, as long as we mirror it in the Config type on the front end, we can do minimal processing when we ask for the config. And it means we can have simpler additions to the config system.

[ThanGerlek]

I'm not sure I understand the problem--is this a backend change, or a frontend refactor? The backend Config system certainly feels a bit messy (at least to me), but the frontend actually looks fairly well centralized. Especially given what we talked about in 340, about how a DTO and its corresponding Model class (the Config type and the config data store) should be separate--one is purely data, and the other has validation and logic. That being said, obviously I'm not too familiar with the frontend--am I missing what you're proposing?

[webecke]

Currently, the way the front end storage is structured, to add a new config option, you have to set up three different things (all in the Config store, but its still a hassle, and as more and more things get added, it seems pretty messy).

This is really more of a full stack change, I want to make some changes to how the back end processes config and also how it sends it to the front end.