Reland "Use existing kUserKeyPair keys during key creation, if possible."

This is a reland of 657a8c539a653fdd91dacd7a78a9fe88f6f706c9

Original change's description:
> Use existing kUserKeyPair keys during key creation, if possible.
> 
> In CyptAuth v2 Enrollment, the user key pair--also known as
> CryptAuthKeyBundle::Name::kUserKeyPair or "PublicKey"--has special
> standing in order to 1) accommodate any existing key from v1 Enrollment
> and 2) enforce that the key is not rotated. Only one user key pair
> should exist in its key bundle, and it should be an active, P-256 key
> with handle "device_key".
> 
> It is possible that CryptAuth could request the creation of a new user
> key pair even if the client sends information about an existing key in
> the SyncKeysRequest. If this happens, the client should re-use the
> existing user key pair key material when creating a new key. At the end
> of the enrollment flow, the existing key will be replaced with this new
> key that has the same public/private keys, but possibly with a new key
> directive.
> 
> It might seem more efficient to simply ignore the key-creation request,
> but the method outlined above natually fits into the enrollment flow,
> the key directive will be updated, and the client will be able to
> provide CryptAuth with an EnrollKeys request, which it might be
> expected.
> 
> Bug: 899080
> Change-Id: I3a4a63aa902090698ecb619bc7af78ff1e790c23
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1504121
> Commit-Queue: Josh Nohle <nohle@chromium.org>
> Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#638327}

Bug: 899080
Change-Id: Ia5f835b662d8d944859300faf2ea4cde351fa18b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1509357
Reviewed-by: Kyle Horimoto <khorimoto@chromium.org>
Commit-Queue: Josh Nohle <nohle@chromium.org>
Cr-Commit-Position: refs/heads/master@{#638782}
10 files changed