[GOT-32] Reconsider the .json validator configuration file

[jsign]

The current config.json validation configuration file looks reasonable, but I believe it has some problems.

In the same configuration file, we have two big groups of configurations:

• Protocol level configurations: TableContraints, QueryConstraints, SC-addresses, etc.
• Validator level configurations: wallet addresses, private keys, port numbers, etc.

In my opinion, a problem arises when we do some protocol-level configuration change. If people use that config.json configuration file with docker-compose, if we edit any field, it might conflict with any other edition the validator has done in the file. For example, it feels very odd if the validator edited the port number or any other validator-related configuration.

Moreover, the "Protocol level configuration" fields shouldn't be changed by validators since they're part of the protocol. This makes the config.json file be somewhat confusing.

If I'm a validator, and I look at config.json, it isn't clear which fields I can change and which ones I must not change. I feel it would be better to have these two groups live in different places. For example, it might make sense to leave the protocol level configurations hard-coded and migrated by the code in the SQLite table and not in the config file. (This is just an idea).

We should reflect on this and see if we can do better. Open to suggestions.

_GOT-32

[jsign]

Adding a note: we should probably move the config.json and probably all the state out of sub-folders of the repo to avoid conflicts when updating.

[joewagner]

The idea of splitting the config into two groups, protocol level, and validator level, makes sense to me. Another way to show the separation of these two might be, values committed to this repo, and values that are not committed (not a hard rule, just an example). Anywhere we find ourselves wanting to add "[FILLME]" that might be a value that would go in validator config.

re: move config out of sub folders. Big plus one from me. A thing that might be related to both discussions here is the .env_* files that are ignored by git.
As an idea, what if we move these all to the top level of the repo and for each of these files created a commited example with a corresponding name example.env_*? These example files could have all possible fields withe "[FILL_OR_REMOVE_ME]" as the value. This would make it fairly easy for node runners to come in and figure out what config they might want to customize.