cryptsetup: if keyfile is specified as AF_UNIX socket in the fs, connect to it, and read key data from it - #17524

We have easy support for this, hence use it for privileged key data.

…EADABLE when reading PEM secret key

It's secret data, hence use the appropriate flags.

…size

Now that we can read from offsets/with size, let's port the cryptsetup
PKCS#11 key file logic over to read_full_file_full().

…ile_full()

Previously, we'd load the file with libcryptsetup's calls. Let's do that
in our own, so that we can make use of READ_FULL_FILE_CONNECT_SOCKET,
i.e. read in keys via AF_UNIX sockets, so that people can plug key
providers into our logic.

This provides functionality similar to Debian's keyscript= crypttab
option (see → systemd#3007), as it allows key scripts to be run as socket
activated services, that have stdout connected to the activated socket.
In contrast to traditional keyscript= support this logic runs stuff out
of process however, which is beneficial, since it allows sandboxing and
similar.

Let's move the 3rd way how cryptsetup acquires key files to
read_file_full() too.

Since load_key_file()'s raison d'etre now is just the search path logic,
let's rename the function to find_key_file().

The comment is pointless, ECC systematically doesn't allow
encryption/decryption directly, only RSA does that. If you want to use
ECC for asymmetric encryption/decryption you have to combine it with key
exchange scheme and symmetric scheme. This all is not a limitation of
the Yubikey, hence don't claim so. It's just how ECC is.