Migrating generated files from the facts subsystem to the vars subsystem is now possible.
HowTo:
1. declare `clan.core.vars.generators.<generator>.migrateFact = my_service` where `my_service` refers to a service from `clan.core.facts.services`
2. run `clan vers generate your_machine` or `clan machines update your_machine`
Vars will only be migrated for a generator if:
1. The facts service specified via `migrateFact` does exist
2. None of the vars to generate exist yet
3. All public var names exist in the public facts store
4. All secret var names exist in the secret fact store
If the migration is deemed possible, the generator script will not be executed. Instead the files from the public or secret facts store are read and stored into the corresponding vars store
The default value for clanDir did not make sense, as it pointed to the directory of the module definition
Also, we should not have a default at this level as all.
Home should not always be set by default.
In the UI we can suggest it, but it catches a lot of state you might not
want to back up.
The default has been moved to be automatically set by vm's in `vm.nix`.
This filters the secrets to only include the secrets managed under `per-machine` and `shared`,
otherwise new deployments will fail, when using the vars module for multiple machines:
```
[vyr] /nix/store/[…]sops-install-secrets: failed to decrypt '/nix/store/[…]/sops/vars/per-machine/draper/garage/admin_token/secret': Error getting data key: 0 successful groups required, got 0
```
This doesn't fix all the edge cases with this approach.
We get a similar error if we deploy shared vars that are not
encrypted for our machine key. This needs to be addressed when
implementing the shared vars functionality.