Currently, linked protectors use filesystem link files of the form
"UUID=<uuid>".  These links get broken if the filesystem's UUID changes,
e.g. due to the filesystem being re-created even if the ".fscrypt"
directory is backed up and restored.

To prevent links from being broken (in most cases), start storing the
mountpoint path in the link files too, in the form
"UUID=<uuid>\nPATH=<path>\n".  When following a link, try the UUID
first, and if it doesn't work try the PATH.  While it's possible that
the path changed too, for login protectors (the usual use case of linked
protectors) this won't be an issue as the path will always be "/".

An alternative solution would be to fall back to scanning all
filesystems for the needed protector descriptor.  I decided not to do
that, since relying on a global scan doesn't seem to be a good design.
It wouldn't scale to large numbers of filesystems, it could cross
security boundaries, and it would make it possible for adding a new
filesystem to break fscrypt on existing filesystems.  And if a global
scan was an acceptable way to find protectors during normal use, then
there would be no need for link files in the first place.

Note: this change is backwards compatible (i.e., fscrypt will continue
to recognize old link files) but not forwards-compatible (i.e., previous
versions of fscrypt won't recognize new link files).

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

When the root user creates a login protector for a non-root user, make
sure to chown() the protector file to make it owned by the user.
Without this, the protector cannot be updated by the user, which causes
it to get out of sync if the user changes their login passphrase.

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

As per the feedback at https://github.com/google/fscrypt/issues/115
where users didn't understand that the recovery passphrase is important,
restore the original behavior where recovery passphrase generation
happens automatically without a prompt.  This applies to the case where
'fscrypt encrypt' is using a login protector on a non-root filesystem.

However, leave the --no-recovery option so that the recovery passphrase
can still be disabled if the user really wants to.  Also, clarify the
information provided about the recovery passphrase.

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

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

ErrBadOwners:
	Rename to ErrDirectoryNotOwned for clarity, move it from
	cmd/fscrypt/ to metadata/ where it better belongs, and improve
	the message.

ErrEncrypted:
	Rename to ErrAlreadyEncrypted for clarity, and include the path.

ErrNotEncrypted:
	Include the path.

ErrBadEncryptionOptions:
	Include the path and bad options.

ErrEncryptionNotSupported:
ErrEncryptionNotEnabled:
	Don't wrap with "get encryption policy %s", in preparation for
	wrapping these with filesystem-level context instead.

Also avoid mixing together the error handling for the "get policy" and
"set policy" ioctls.  Make it very clear how we're handling the errors
from each ioctl.

ErrProtectorName:
	Rename to ErrLoginProtectorName for clarity, and include the
	name and user.

ErrMissingProtectorName:
	Include the correct protector source.

ErrDuplicateName:
	Rename to ErrProtectorNameExists for clarity, and remove a level
	of wrapping by including the name directly.

ErrDuplicateUID:
	Rename to ErrLoginProtectorExists for clarity, and remove a
	level of wrapping by including the user directly.

Test encrypting a directory using a login (pam_passphrase) protector.