cryptsetup: allow customizing cache behavior

[kszczek]

The new "password-cache" option allows customizing behavior of the ask-password module in regards to caching credentials in the kernel keyring. There are 3 possible values for this option:

• read-only - look for credentials in kernel keyring before asking
• on - same as read-only, but also save credentials input by user
• off - disable keyring credential cache

Currently the cache is forced upon the user and this can cause issues. For example, if user wants to attach two volumes with two different FIDO2 tokens in a quick succession, the attachment operation for the second volume will use the PIN cached from the first FIDO2 token, which of course will fail and since tokens are only attempted once, this will cause fallback to a password prompt.

[github-actions]

Important

An -rc1 tag has been created and a release is being prepared, so please note that PRs introducing new features and APIs will be held back until the new version has been released.

[kszczek]

Overlooked an issue with the default value for PKCS#11 tokens, fixed it. Sorry for the noise.

[yuwata]

Several superficial comments.

[kszczek]

After performing some additional tests with strace -e add_key,request_key,keyctl I've discovered that currently the cache behavior is somewhat inconsistent. When attempting to unlock with a TPM2 device via token plugin (the prioritized execution path), the cache is checked for the PIN, but when running with SYSTEMD_CRYPTSETUP_USE_TOKEN_MODULE=no set, thus skipping the plugins, the cache is not checked for the PIN.

This PR makes the behavior consistent in both execution paths, but in doing so it breaks backward compatibility in this (probably very uncommon) edge case.