move secrets from sops lookup plugin to sops vars plugin

This makes secret configuration and usage a good bit cleaner.

docs/setting_up_secrets_using_sops_for_a_new_host.md

@@ -1,15 +1,20 @@
 # Setting Up Secrets Using SOPS for a New Host
 
-1. Add a new creation rule for the hosts resources directory.
+Because we're using the `community.sops.sops` vars plugin, the SOPS-encrypted secrets get stored in the inventory.
+
+1. Add a new creation rule for the hosts `host_vars` file.
    It should probably hold all admin keys.  
    You can use existing creation rules as a reference.
-2. Create a file containing the relevant secrets in the hosts resources directory.
+2. Create a SOPS secrets file in the `host_vars` subdirectory of the relevant inventory.
+   The name of the file should be in the format `[HOSTNAME].sops.yaml` to get picked up by the vars plugin and to match the previously created creation rule.  
    This can be accomplished with a command similar to this:
    ```
-   sops resources/[chaosknoten|z9]/HOSTNAME/secrets.yaml
-   ```
-3. In the following an example on how to then use the `community.sops.sops` lookup plugin to use a secret for a host.
-   In this particular instance the lookup plugin gets used to set the `nextcloud__postgres_password` variable in an inventories `host_vars` file to the secret value of the `DB_PASSWORD` YAML key:
-   ```yaml
-   nextcloud__postgres_password: "{{ lookup('community.sops.sops', 'resources/chaosknoten/cloud/secrets.yaml', extract='[\"DB_PASSWORD\"]') }}"
+   sops inventories/[chaosknoten|z9]/host_vars/[HOSTNAME].secrets.yaml
    ```
+3. With the editor now open, add the secrets you want to store.
+   Because we're using the `community.sops.sops` vars plugin, the stored secrets will be exposed as Ansible variables.  
+   Also note that SOPS only encrypts the values, not the keys.  
+   When now creating entries, try to adhere to the following variable naming convention:
+   - Prefix variable names with `secret__`, if they are intended to be used in a template file or similar. (e.g. `secret__netbox_secret_key: secret_value`)
+   - Otherwise, if the variable is directly consumed by a role or similar, directly set the variable. (e.g. `netbox__db_password: secret_value`)
+4. Now that the secrets are stored, they are exposed as variables and can simply be used like any other variable.