WriteRecoveryInstructions() opens the recovery README with os.OpenFile
using O_WRONLY|O_CREATE without O_NOFOLLOW. When fscrypt encrypt runs
as root, this allows a local attacker to place a symlink at the recovery
file path, causing root to write through the symlink and then fchown the
target file to the attacker. Adding O_EXCL|O_NOFOLLOW aligns with the
existing security pattern in filesystem.go:608 and filesystem.go:747.

github.com/golang/protobuf/proto has been deprecated in favor of
google.golang.org/protobuf/proto, so migrate to the non-deprecated one.

Since commit 4c7c6631cc5a ("Set owner of login protectors to correct
user"), login protectors are made owned by the user when root creates
one on a user's behalf.  That's good, but the same isn't true of other
files that get created at the same time:

- The policy protecting the directory
- The protector link file, if the policy is on a different filesystem
- The recovery protector, if the policy is on a different filesystem
- The recovery instructions file

In preparation for setting all metadata files to mode 0600, start making
all these files owned by the user in this scenario as well.

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

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.

Ensure that a failed AddRecoveryPassphrase() doesn't leave around an
unneeded protector file.

If the login protector was just created by the same 'fscrypt encrypt'
command, then policy.Context.Config.Source will be pam_passphrase.  This
needs to be overridden to custom_passphrase when creating the protector
for the recovery passphrase.

This fixes the following error:

    fscrypt encrypt: login protectors do not need a name

Resolves https://github.com/google/fscrypt/issues/187
Update https://github.com/google/fscrypt/issues/186

If a user re-installs their system (or otherwise loses the /.fscrypt
directory on the root filesystem) they also lose access to any login
passphrase-protected directories on other filesystems, unless additional
protectors were manually added.  This can be unexpected, as it may be
expected that the old login passphrase would still work.

We can't really fix this by storing a login protector on every
filesystem because:

- If a user were to have N login protectors, it would take them N times
  longer to log in, as every login protector would need to be unlocked.

- If a user were to change their login passphrase while any external
  volumes were unmounted, login protectors would get out of sync.

- It's preferable that an external volume isn't unlockable by itself
  using only a login passphrase, as login passphrases are often weak.

Instead, generate a recovery passphrase when creating a login
passphrase-protected directory on a non-root filesystem.

The recovery passphrase is added as a custom_passphrase protector, thus
giving the policy two protectors: one pam_passphrase and one
custom_passphrase.  Then this passphrase is written to a file in the new
encrypted directory.  Writing the passphrase to a file here is okay
since it's encrypted, but it's obviously useless by itself; it's up to
the user to store this passphrase somewhere else if they need it.

Use a recovery passphrase instead of a "recovery code" that encodes the
policy key directly because a passphrase is more user-friendly: it can
safely be made much shorter than a key, and it works just like any other
fscrypt protector.  Also, it's not as critical to allow recovery when
the .fscrypt directory on the *same* filesystem is deleted.

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