Add intermediary form config representation

[signebedi]

A perennial problem. Writing forms as a python dictionary is powerful but works against customization, eg. in the UI. Then, we specify a FORM_CONFIG_PATH str in the app config, which defaults to instance/form_config.json. Then, we load this file and validate it through our pydantic model each time the API is called, allowing rapid iteration.

[signebedi]

We probably then need to create a place for admins to define whitelisted custom callables that they can reference in their JSON configs. We also need to predefine a few, and write a template function or class that assumes certain kwargs will be passed, like form_name, etc. We also need to find a way to handle python type representations in JSON strings. Finally, we need to add a bunch of validation checks against the JSON config at app start up, and when there is a change to the config - eg. in the admin console.

This eventually will result in a new admin route for form configuration.

[signebedi]

This approach allows us to write everything in a config file and, put another way, everything is editable at runtime. The great thing about the form config is that it is encapsulated in a callable: libreforms_fastapi.utils.pydantic_models:load_form_config(). This means that it can be updated at runtime without needing an app reload. The problem with the dotenv configs is that they are not callable but static and set at app startup, see #5 for discussion of approaching configs as a callable. Finally, we are thinking about writing some docs, see #124. This would ideally be markdown documentation that can be edited through a programmatic interface.

[signebedi]

Add support for plugin callables for field options and custom visualizations
I think that we can probably refer to these callables as plugins and define a plugin path as an app config... something like PLUGIN_PATH. We should consider allowing users what kwargs should be passed to the plugin callables. We probably can't get around enumerating the supported kwargs.. something like:

1. doc_db
2. user_list
3. group_list
4. signing_list

Or maybe we allow admins to request all relational and document database data. I don't think we should automatically pass this data to all plugin callables, that would be bad security practice.

[signebedi]

Add support for multiple form config files
Increasingly, I am thinking that we create support for multiple form config files, which can store one or more forms, but which prefer to store just one - and which the UI enforces as one-form-to-one-file as a general practice. This is more modular and less error prone.

[signebedi]

Callables are outside the scope of this specific issue, but types are not. As such, part of me truly is beginning to believe that JSON is not the ideal intermediate representation system here... yaml, despite giving us another dependency (pyyaml) might actually do the trick much better.

[signebedi]

[api] [admin] add admin read form config route
The purpose of this route will be to permit admins to see the content of the form config file in plaintext.

[signebedi]

[api] [admin] add admin update form config route
The purpose of this route will be to permit admins to make changes to the content of the form config file in plaintext.