DID Resolution

[clehner]

This PR adds a new package implementing DID Resolution to fetch DID Documents. Supporting changes to the top-level package are included. We use a Cargo Workspace to make the two packages share build data.

We add a DIDResolver trait with resolve and resolve_stream functions, corresponding to the abstract functions for DID Resolution defined in DID Core § 8.1 DID Resolution. We implement the trait with HTTPDIDResolver, a HTTP(S) binding according to DID Resolution § 7.1 HTTP(S) Binding, compatible with Universal Resolver (#9).

HTTPDIDResolver implements resolve_stream in terms of resolve, which involves deserializing and then re-serializing data, as described in w3c/did-resolution#57. Ideally, I think HTTPDIDResolver's resolve_stream would pass through the document stream from the HTTP server, and resolve would be implemented in terms of resolve_stream. But this is pending specification of HTTP(S) binding for resolveStream in DID Resolution. (However, it may be possible currently to pass through the stream if the client requests via the accept input metadata parameter to get only the DID document, not the resolution result including metadata. I did not implement that yet as I think it is under-specified, and Universal Resolver doesn't seem to implement that option either).

In tests, we implement a resolver returning static DID documents, and a local HTTP server implementing the server-side of the HTTP(S) Binding for DID Resolution. That server could be later expanded into a public module.

We also define structs for DID Resolution Input Metadata and DID Resolution Result, including DID Resolution Metadata and DID Document Metadata, according to DID Resolution § 6.

The resolve and resolve_stream functions that I have added here do not return a Result but include any error in the error property of the ResolutionMetadata struct. Error property values are defined in DID Core, DID Resolution, and DID Specification Registeries. However, to do this, I am using error values not specified in the specs, and converting Errors into strings to put in that property. I'm not sure if this is the best way. I opened w3c/did-core#402 to try to get guidance for this. An alternative would be to wrap the return values of resolve and resolve_stream in a Result, and return a crate Error in the case of errors not serializable into spec-defined errors. Then the implementation could comply with the specs strictly, while still allowing fine-grained error handling. Callers would have to check that the result is ok and that there is no error property set, similar to checking the status code of a HTTP response. In that case we might then be able to improve the API by using an enum for the error property instead of the current string constants.

[clehner]

Rebased.

Changed DID resolution result profile URL, as changed in: w3c/did-resolution@68ac2a7