Quick follow up to PR #2781, this commit does the same kind of logic but
for machines instead of users and groups.
Note that this only affects the `clan secrets machines remove`
sub-command, and that `clan machines delete` still leaves unusable
secrets & vars behind. This can be addressed in a different change.
We need to remove all keys that were in the group from affected secrets.
With this change we now take `group_name` as an argument in
`{add,remove}_member`, which is a little bit more readable than
`group_folder.parent.name`, and helps DRY the code a bit.
When users or groups are updated :
- Check that keys are properly updated on sops secrets;
- Check that no dangling symlinks are left behind in sops secrets.
And when an user is removed from the clan, check that it is removed from
the groups it belonged to.
This doesn't check this works for vars explicitly, since they share the
same logic, see `secret_paths.extend(list_vars_secrets(flake_dir))` in
commit 7466445653.
Those improvements allow us to validate that #2659 is indeed fixed, and
tell us that we need to make the same kind of fixes for machines and
groups. For groups this is straightforward, and for machines, when one
is deleted, I wanna discuss first whether we want to delete all its
secrets as well.
Dynamically extending the python path at runtime is bad for developer experience, as this is not understood by the text editor and therefore jump to definition etc. does not work.
-> Better to remove the dynamic inclusion and force developers to specify the import correctly.
