ErrBadConfig:
	Fix backwards wrapping, include the bad config, and make it
	clear that this is an internal error.

ErrBadConfigFile:
	Fix backwards wrapping, include the config file location, and
	adjust the suggestion slightly.

ErrConfigFileExists:
	Include the config file location.

ErrNoConfigFile:
	Include the config file location, and adjust the suggestion
	slightly.

There's no real need to allow users to choose the key description prefix
(a.k.a. the "service"), since on ext4 and f2fs we can just use "ext4"
and "f2fs" for compatibility with all kernels both old and new, and on
other filesystems we can just use "fscrypt".  So, let's do that.

Since this removes the point of the "--legacy" option to 'fscrypt setup'
and the "compatibility" field in /etc/fscrypt.conf, remove those too.

Specifically, we start ignoring the "compatibility" in existing config
files and not writing it to new ones.  The corresponding protobuf field
number and name are reserved.  We stop accepting the "--legacy" option
at all, although since it was default true and there was no real reason
for anyone to change it to false, probably no one will notice.  If
anyone does, they should just stop specifying the option.

Note that this change only affects user keyrings and thus only affects
v1 encryption policies, which are deprecated in favor of v2 anyway.

Implement adding/removing v2 encryption policy keys to/from the kernel.
The kernel requires that the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and
FS_IOC_REMOVE_ENCRYPTION_KEY be used for this.  Root is not required.

However, non-root support brings an extra complication: the kernel keeps
track of which users have called FS_IOC_ADD_ENCRYPTION_KEY for the same
key.  FS_IOC_REMOVE_ENCRYPTION_KEY only works as one of these users, and
it only removes the calling user's claim to the key; the key is only
truly removed when the last claim is removed.

Implement the following behavior:

- 'fscrypt unlock' and pam_fscrypt add the key for the user, even if
  other user(s) have it added already.  This behavior is needed so that
  another user can't remove the key out from under the user.

- 'fscrypt lock' and pam_fscrypt remove the key for the user.  However,
  if the key wasn't truly removed because other users still have it
  added, 'fscrypt lock' prints a warning.

- 'fscrypt status' shows whether the directory is unlocked for anyone.

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.

Refer to the target User as 'targetUser' rather than simply 'target'.
This will help avoid confusion when we add support for the filesystem
keyring, since then the Mount will also be a "target".

Use the new name for fscrypt constants and structures which have been
given a new name.

Also use the named constant for the DIRECT_KEY fscrypt policy flag.

No change in behavior.  This is just preparing for future work.

Make it clear that this refers to a type of filesystem such as "ext4",
rather than to a specific filesystem instance.

These were found by a combination of manual review and a custom script
that checks for common errors.

Also removed an outdated sentence from the comment for setupBefore().

This user is used with policies to interface with the keryings and with
protectors to indicate which user's login passphrase should be used to
protectors of type pam_passphrase.