Add X25519 key and verification method support

[cycraig]

Description of change

Adds support for X25519 cryptographic key pairs for performing Elliptic Curve Diffie-Hellman (ECDH) key exchange operations and the X25519KeyAgreementKey2019 verification method type.

There are some open questions about the design of the KeyExchange trait which uses PhantomData rather than generics (in line with current conventions for Sign and Verify) and several TODOs related to removing MerkleKeyCollections in #715.

Added

• Add MethodType::X25519KeyAgreementKey2019.
• Add KeyType::X25519.
• Add MethodSecret::X25519.
• Add X25519 KeyExchange implementation.
• Add Diffie-Hellman key exchange example.
• Add MethodData Wasm bindings.

Changed

• Change KeyPair::try_from_ed25519_bytes to try_from_private_key_bytes.
• Rename MethodData::new_b58 to new_base58.
• Rename VerificationMethod::key_type to type_.
• Rename VerificationMethod::key_data to data.

Removed

• Remove KeyPair::new_ed25519.

Links to any relevant issues

Fixes #671.

Type of change

• Bug fix (a non-breaking change which fixes an issue)
• Enhancement (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Fix

How the change has been tested

Local tests and new examples work.

Change checklist

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[HenriqueNogara]

LGTM

[PhilippGackstatter]

Looks good to me!

Some comments regarding the outstanding questions.

[PhilippGackstatter]

I think that makes sense, at least in the current situation. Typically, we cannot use a KeyPair interchangeably, e.g. a document can only be created from an Ed25519KeyPair. On the other hand, for generation or storage we don't care about the type, so perhaps we have to retain the KeyPair type as an abstraction? (Not thought through.)

[cycraig]

Yeah I'm hesitant to do a KeyPair refactor at this point since it has sweeping implications everywhere. One concern I have is that with introducing specific types we multiply the number of structs we have to make bindings for.

E.g. currently we have KeyPair with Public and Private keys represented as strings/UInt8Array soon, so basically one type exposed to the bindings. With a refactor we might have 6 different structs:

• Ed25519KeyPair
• Ed25519Private
• Ed25519Public
• X25519KeyPair
• X25519Private
• X25519Public

And more for each new KeyType we choose to support. Note that the specific types for keys may be important for places where we only want/need the public key, such as creating a new verification method or only allowing Ed25519 for creating a new IotaDocument or IotaDID. We've largely moved away from requiring KeyPairs in function parameters where the private key is not required.

If we do go ahead with such a refactor I think a KeyPair trait would be useful for generalization, e.g.

trait KeyPair {
  type Public;
  type Private;

  fn public(&self) -> &Self::Public;
  fn private(&self) -> &Self::Private;
  fn key_type(&self) -> KeyType;
}

I don't think that will be in this PR, however.

[PhilippGackstatter]

Thanks for the explanations. It's fine to leave this for a future PR. Turning KeyPair into a trait is what I had in mind, too, that sounds good! I agree that we need to carefully consider the impact before going ahead, specifically for Wasm.