Extend Config to be bootstrappable, like data is bootstrappable ( needs more design )

[joe-getcouragenow]

The data is able to be bootstrapped via CLI and this makes it quick to setup a server.

PRECONDITION: Backup and restore already done. So that Remote Config can then we tried. Also backup and restore is more important right now i think.

NOT READY: The GRPC API for config bootstrapping needs to be looked at

• config replaces, whereas data adds.
• remote will want to group doing config and data bootstrapping and a few more things. So it shoudl archestrate on top of the base GRPC API of the CLI and Server.

We can do the same for the config making it replacable via the CLI and gain:

• From a new server, you can set it up by applying a config via cli and then data via cli. fast and easy.
• makes it quicker to test config changes, like SMTP etc.
• allow mass remote deployment / updates via Google storage. Will require adding a "remote config URL" to the config. *PreCondition: Do this once the backup system with Google storage is done.

But to do it we need to move the SuperAdmin from being in the Data bootstrap and DB to be:

• default superAdmin user hardcoded into code, and override in config. This is fine because the config is encrypted.
• default username and password is "superadmin, superadmin" mapped to Role "SuperAdmin".
• Config can only change the password. It cannot change the username, because that will screw up the custom checking DAL code. Call it "SuperAdminPassword" in the config and code i think.
• logic for change or new for superadmin, does not enforce a email check, because its not viable with a default superadmin user name called "superadmin".

code changes and logic:

1. Change the SuperAdmin to be hard coded with config override. SO the login dal DAL first checks in config for username called exactly "superadmin", and if it the special username of "superadmin" then checks password in config, and if not there checks against hard coded password. This logic applied for Flutter and CLI clients.

2. When logging into CLI and GUI as user "superadmin", screen should warn user if using hardcoded superadmin. This is to prevent the classic "not bothering to change default password" security gotcha. It can use the current a grpc / flash message architetcure. We use it for errors, but can be use it for feedback too without hacking.

3. Remove SuperAdmin from data bootstrap yaml and hence the GRPC API, so it is not part of the data bootstrap at all. The GRPC API and hence data bootstrap still needs to provide modelling / changing standard user accounts.

4. Make a specific Service method just for SuperAdmin. Its logic and modeling is so different it needs its own API, code.

5. make config changable via CLI. Currently the CLI only allows data bootstrapping.

6. make server restart automatic on config change. When the config is changed, the server wont see it unless it restarts. We should make it such when a user bootstraps the config via the CLI, the server automatically restarts, and a mass config change happening via Google Storage later, its self healing. SO then do the restart code just at the end of the server side function once the config is transacted to disk. This will mean the user of the CLI will not get any feedback when they activate a config change, but we cant do much except add this warning to the Cobra help text.