ErrAccessUserKeyring:
	Include the user, and fix the backwards wrapping.

ErrSessionUserKeyring:
	Include the user.

ErrKeyAdd:
ErrKeyRemove:
ErrKeySearch:
ErrLinkUserKeyring:
	Replace these with one-off unnamed errors because they are
	never checked for, and this makes it easier for the callers to
	provide better messages, e.g. fixing the backwards wrapping.

KEYCTL_INVALIDATE has complicated semantics: it doesn't remove the key
from the keyring right away but rather marks it as being invalidated,
and then removes it asynchronously.  This nondeterministically breaks
the heuristic I'm implementing to detect v1-encrypted directories being
incompletely locked.

Instead, switch to KEYCTL_UNLINK, which has simpler semantics.

Note that Android uses KEYCTL_UNLINK too.

Linux v5.4 and later allows fscrypt keys to be added/removed directly
to/from the filesystem via the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and
FS_IOC_REMOVE_ENCRYPTION_KEY.  Among other benefits, these fix the key
visibility problems that many users have been running into, where system
services and containers can't access encrypted files.

Allow the user to opt-in to using these new ioctls for their existing
encrypted directories by setting in their /etc/fscrypt.conf:

	"use_fs_keyring_for_v1_policies": true

Note that it can't really be on by default, since for v1 policies the
ioctls require root, whereas user keyrings don't.  I.e., setting this to
true means that users will need to use 'sudo fscrypt unlock', not
'fscrypt unlock'.  v2 policies won't have this restriction.

In preparation for introducing support for the new filesystem-level
keyrings, move the existing user keyring management code from
security/keyring.go and crypto/crypto.go into a new package, 'keyring'.

This package provides functions AddEncryptionKey, RemoveEncryptionKey,
and GetEncryptionKeyStatus which delegate to either the filesystem
keyring (added by a later patch) or to the user keyring.  This provides
a common interface to both types of keyrings, to the extent possible.