bug#45512: Feature Request: keyfile support for LUKS volume opening

[raid5atemyhomework via Bug reports for GNU Guix <bug-guix@gnu.org>]

Consider the following use-case:

* I have a boot device including a partition backing `/`.
* My `/home` is on a separate RAID array, because my homework is important and I would like to not lose it.
* Each disk in the RAID array is *separately* LUKS-encrypted.
  * This allows me to decommission any disk in the array by destroying its LUKS header with `cryptsetup erase` on the decommissioned disk.
  * While I could instead encrypt the RAID block device, if I decommission one of the members of the array, it might contain the LUKS header for the encrypted device, and I am not confident that my passphrase "RAID5 is not a good dog" is not known by anyone else.
    I also cannot `cryptsetup erase` the RAID block device as that would destroy all the data in the entire array.
  * For example, my classmates want to copy my homework, so if for example one of the disks starts having trouble and I decide to send it back to the seller for a replacement, my classmates might intercept the disk in the hope of copying my homework.

Unfortunately, if I have several disks in my RAID array, then boot would be painful as I would need to enter my passphrase for each disk in the array.

In this case, I would appreciate instead using a keyfile.

* I *also* encrypt my `/` root partition.
  * I use my passphrase "RAID5 is not a good dog" for this partition.
* In the `/root` directory, I generate a keyfile by `dd if=/dev/random bs=32 of=/root/keyfile`.
* I individually LUKS-encrypt each disk in the array using the keyfile `/root/keyfile`.

Then, on boot:

* I `cryptsetup` my `/` root partition and enter my passphrase.
* I mount `/`.
* Each of my RAID disks is then opened by `cryptsetup` but specifying a `--key-file` as `/root/keyfile`.
* I assemble my array and open the LVM container on top and mount my `/home`.

This means that at boot, I just input a passphrase once, and this decrypts a keyfile that can be used to open all the other LUKS devies on my system.

This is a important use-case:

* If I LUKS-encrypted my `/home` only, I run the risk that the LUKS header is on a disk that I am decommissioning.
  Then, a classmate with possession of my passphrase "RAID5 is not a good dog" and who intercepts the decommissioned disk may be able to recover part of my precious homework and submit it to my professor and get good grades.
* If instead I have a keyfile on my encrypted partition, my classmate not only needs to know my passphrase "RAID5 is not a good dog" and have intercepted the decommissioned disk, they *also* have to gain access to my boot disk, which is safely inside my computer tower.
* Because the keyfile is stored only on the `/root` directory, I can easily destroy all my data (in case my classmates try to get at my actual computer tower) by doing a `cryptsetup erase` on the root partition.

It also allows other use-cases:

* If I am using HDDs in the RAID array, I might get tired of the low speed, so I might decide to use a `bcache` or `dm-cache` with an SSD cache to speed up my array.
  * The cache SSD must also be encrypted, otherwise if I decommission my SSD cache device then it might contain my precious homework in unencrypted form.
    With a keyfile stored on an encrypted root partition, I can encrypt my SSD cache without adding yet another passphrase to enter during boot.

It seems to me that this model where the only device with a LUKS keyslot containing a pasphrase would be the root partition, and all other encrypted devices use a keyfile on the root partition, is generally a good basis for ensuring that my data is difficult for somebody else to access even as I upgrade my system.

There is of course the risk that the device with the root partition fails and thus accidentally destroy all my data, thus reducing my reliability, but I could `xxd /root/keyfile`, write down the hexdump on a piece of paper, then store that piece of paper in the same facility where I store all my gold bullion.
Similarly I could instead use a keyfile generated from a dozen words from `/etc/dictionaries-common/words`, which would be easier to store on paper.

To implement this, there is some overlap with https://issues.guix.gnu.org/45497
Basically, we need as well an `arguments` field in `mapped-device` records, where we can add `#:key-file` for LUKS mapped devices.

Another is that we also need to have `dependencies` for `mapped-device`s, not just for `file-system`s.
Crucially, a `mapped-device` might depend on a `file-system` --- in this case, a LUKS-encrypted container that uses a keyfile must wait for the filesystem that contains the keyfile to get mounted.
In particular, I notice that existing `mapped-device-kind`s have ad hoc "wait for sources to come online" waitloops, when we should instead be using proper Shepherd `requirement` specifications.

A complication here is that I am uncertain how Guix handles the root filesystem from the `initrd`.