Support verification methods with the same fragment

[cycraig]

Description of change

This updates MethodQuery to match on the DID as well as the fragment when the query includes a full DID-Url.

This fixes the following edge-cases:

• adding a method to a document with an ID field of a different DID (typically a controller DID Document) but the same fragment as an existing method.
• resolving such a method by specifying its full ID (previously would return the first method that matched the fragment).
• verifying a document signed with such a method.

The specification seems to allow adding methods and services to a DID Document which reference a different DID. We added support for signatures from such methods in #458 but duplicate fragments was still an edge-case.

NOTE: this affects all functions that resolve methods (including verifying signatures since that resolves the method used to sign) since it affects the core behaviour of OrderedSet.

Example

The following document has a signing method from a controller DID document (this is a workaround since we do not support signatures from controllers simply referenced as the controller of the DID Document). The signature was created by the private key corresponding to the controller method.

Note how both methods have the same #sign-0 fragment. This is not advised but should still be legal according to the specification.

Before this PR the document would fail verification since the library would incorrectly resolve did:iota:HGE4tecHWL2YiZv5qAGtH7gaeQcaz2Z1CR15GWmMjY1M#sign-0 as the signing method instead of did:iota:A73GoJ7N6qHEdSfoist6YR4MCDteuhiinUmaMV9vSUcZ#sign-0 despite the full ID being specified in "verificationMethod".

{
  "doc": {
    "id": "did:iota:HGE4tecHWL2YiZv5qAGtH7gaeQcaz2Z1CR15GWmMjY1M",
    "capabilityInvocation": [
      {
        "id": "did:iota:HGE4tecHWL2YiZv5qAGtH7gaeQcaz2Z1CR15GWmMjY1M#sign-0",
        "controller": "did:iota:HGE4tecHWL2YiZv5qAGtH7gaeQcaz2Z1CR15GWmMjY1M",
        "type": "Ed25519VerificationKey2018",
        "publicKeyMultibase": "zFJsXMk9UqpJf3ZTKnfEQAhvBrVLKMSx9ZeYwQME6c6tT"
      },
      {
        "id": "did:iota:A73GoJ7N6qHEdSfoist6YR4MCDteuhiinUmaMV9vSUcZ#sign-0",
        "controller": "did:iota:A73GoJ7N6qHEdSfoist6YR4MCDteuhiinUmaMV9vSUcZ",
        "type": "Ed25519VerificationKey2018",
        "publicKeyMultibase": "zEh7rBAVQAFEXXK63Aiku4eqgWJhw5z1VYiVA9tmbveJP"
      }
    ]
  },
  "meta": {
    "created": "2022-01-25T14:11:46Z",
    "updated": "2022-01-25T14:11:46Z",
    "proof": {
      "type": "JcsEd25519Signature2020",
      "verificationMethod": "did:iota:A73GoJ7N6qHEdSfoist6YR4MCDteuhiinUmaMV9vSUcZ#sign-0",
      "signatureValue": "5njR8zSD1setBb135o2SNZ6Zjc58s8xot9nRt5MF2kX9JZXQUxWNxoudJisawG74cXKibSSQdxN11PcsiW5ujqYw"
    }
  }
}

Links to any relevant issues

Fixes issue #457.

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

Tests and Wasm examples pass locally.

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

[PhilippGackstatter]

Looks good to me, thanks for the changes!

[olivereanderson]

Looks good to me!