Since Go 1.16 (which recently became the minimum supported Go version
for this project), the package io/ioutil is deprecated in favor of
equivalent functionality in the io and os packages.  staticcheck warns
about this.  Address all the warnings by switching to the non-deprecated
replacement functions.

If a session is opened for a user twice and the second doesn't have the
AUTHTOK data, pam_fscrypt prints an error message that says it failed to
unlock a protector because AUTHTOK data is missing.  This is misleading
because the protector and its associated policies were already unlocked
by the first session.

To avoid this, move the check for whether the policy is provisioned or
not into policiesUsingProtector().  Also do the same for CloseSession.

Now that it's been requested by users, bring back the "unlock_only"
option, which was originally proposed as part of
https://github.com/google/fscrypt/pull/281 but was dropped in the final
version of that pull request.

Resolves https://github.com/google/fscrypt/issues/357

Update https://github.com/google/fscrypt/issues/350

pam_fscrypt should never need to do anything for system users, so detect
them early so that we can avoid wasting any resources looking for their
login protector.

If the error is anything other than ErrNotSetup, it might be helpful to
know what is going on.

The metadata validation checks introduced by the previous commits are
good, but to reduce the attack surface it would be much better to avoid
reading and parsing files owned by other users in the first place.

There are some possible use cases for users sharing fscrypt metadata
files, but I think that for the vast majority of users it is unneeded
and just opens up attack surface.  Thus, make fscrypt (and pam_fscrypt)
not process policies or protectors owned by other users by default.
Specifically,

   * If fscrypt or pam_fscrypt is running as a non-root user, only
     policies and protectors owned by the user or by root can be used.

   * If fscrypt is running as root, any policy or protector can be used.
     (This is to match user expectations -- starting a sudo session
     should gain rights, not remove rights.)

   * If pam_fscrypt is running as root, only policies and protectors
     owned by root can be used.  Note that this only applies when the
     root user themselves has an fscrypt login protector, which is rare.

Add an option 'allow_cross_user_metadata' to /etc/fscrypt.conf which
allows restoring the old behavior for anyone who really needs it.

If someone runs 'passwd USER' as root, the user is assigned a new login
passphrase without their fscrypt login protector being updated.  Detect
this case and show a warning message using pam_info().

Fixes https://github.com/google/fscrypt/issues/273

All pam_fscrypt configuration guides that I'm aware of say to use the
"lock_policies" option for the pam_fscrypt.so session hook.  The
Debian/Ubuntu pam-config-framework config file has it too.

Make locking the default behavior, since this is what everyone wants.

Existing configuration files that contain the "lock_policies" option
will continue to work, but that option won't do anything anymore.

(We could add an option "unlock_only" to restore the old default
behavior, but it's not clear that it would be useful.  So for
simplicity, leave it out for now.)