No way to fall back to unencrypted config file for K8s encryption

This came up in https://bugs.launchpad.net/charm-kubernetes-master/+bug/1949384 but if the k8s-master charm is deployed on LXD and the vault-kv relation is present, it will fail to create the encrypted loopback device for securing the config file containing the encryption key for K8s and go to a blocked status until the relation is removed, at which point the encryption will not be set up.

It may be that having an encrypted loopback device for the config file is unnecessary, such as if the LXD storage pool is encrypted or if the host machine is using full-disk encryption. The charm should not automatically fall back to not protecting the encryption key, but there should be some way for the admin to indicate that it is ok to proceed without the device, such as a config option.

Alternatively, if we can detect that we're running in LXD (I think we have logic for that somewhere) then we could just skip the Vaultlocker logic by default and rely on documentation to inform about the need for external protection of that config file.