Previously if a user started the app and the last opened clan directory does not exist anymore, it would still show the clan screen but without any machines.
This changes catches this case and throws the user back to the clan selection page
Extends how we parse the contents of `SOPS_AGE_KEY` / `SOPS_AGE_KEY_FILE` / `keys.txt`, allowing a user to prepend a comment before any `AGE-PLUGIN-` secret key entry to indicate its corresponding public key.
For example:
```
AGE-PLUGIN-FIDO2-HMAC-xxxxxxxxxxxxx
```
The comment can use any prefix (e.g. `# public key: age1xxxx`, `# recipient: age1xxx`) as we are looking directly for `age1xxxx` within the line.
This change is necessary to support `age` plugins as there is no unified mechanism to recover the public key from a plugin's secret key.
If a plugin secret key does not have a preceding public key comment, an error will be thrown when attempting to set a secret.
This is a great refactor of the select functionality in the flake class.
This now uses the same parser as the nix code, but runs it in python for
nice stacktraces.
Also we now have a maybe selector which can be used by prepending the
selector with a ?
Tests have been expanded to make sure the code is more stable and easier
to understand
We cannot support dynamic hashInvalidation.
This means the invalidation can change *after* or *before* a 'vars generate'
But not during the generation itself. This causes heavy performance overhead.
Additionally this introduces a fixed-point-iteration (compare: fixed-point-iteration vs. fixed-point-function)
This iteration takes ~ 1min for two bare-bones machine with 1 generator (see: checks/data-mesher)
Invalidation doesn't need to be done after each generator is executed.
We cannot interpolate values from other generators into another
generator. The generators are executed in order. The finalScript of each
generator stays constant.
After the complete closure is generated the caller of generate may
decide to invalidate the flake cache
this functionality is not really useful or used in clan-vm-manager and
therefore should live in the clan-vm-manager.
Not porting the test for now because we probably get rid of the clan-vm-manager soon in favour of the UI.