Add StardustDocumentMetadata, implement StardustDocument methods

[cycraig]

Description of change

Fleshes out the StardustDocument with getters, setters, and a Document implementation for parity with IotaDocument. Also adds StardustDocumentMetadata for the created, updated timestamps.

Update the Stardust create_did example to demonstrate how to increase the deposit amount automatically and destroy the Alias Output.

Added

• Add StardustDocumentMetadata.
• Add many StardustDocument methods.

Changed

• Change StardustDocument to include StardustDocumentMetadata.
• Update iota-client pin to latest commit.
• Update iota-crypto to fix compilation.
• Rename StardustDocument::deserialize_inner to unpack.

Removed

• Remove StardustDocument::deserialize_from_block.
• Remove StardustDocument::tmp_* temporary methods.

Links to any relevant issues

Task of #908.

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

Added unit tests, updated example works.

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.

[PhilippGackstatter]

Good idea, I'll see about that in the client impl.

[cycraig]

It would be nice but I don't know what format the immutable metadata is meant to take for other purposes: they don't have a dedicated created timestamp as far as I know. It might be fine for Alias Outputs used only as DID Documents though.

[PhilippGackstatter]

Not sure about the rename. I feel like "revoke indices" is not very clear in what it does. I think I still prefer revokeCredentials or perhaps revokeCredentialIndices?

[cycraig]

It's to better match the function parameters and reserve the revoke_credentials name for a convenience function that actually takes in a &Credential to extract the status and revocationBitmapIndex automatically (perhaps on the Account). Right now it's assumed that the index and service are known to the revoker, so we don't show how tedious those steps actually are.

[PhilippGackstatter]

I understand the argument against revokeCredentials. I think revokeCredentialIndices wouldn't be too bad and would be more specific than revokeIndices. Just an opinion, entirely optional.

[cycraig]

What about revokeBitmapIndices?

[PhilippGackstatter]

Slightly better, just not entirely clear that it refers to indices that correspond to credentials, in my opinion.
I'm mainly concerned about readability. So when you read through an example and you see account.revokeBitmapIndices("#my-revocation-service", 5);, it doesn't say credential anywhere even though that's what it's ultimately about. But it's probably usually clear from context, so might be fine.

[cycraig]

just not entirely clear that it refers to indices that correspond to credentials

But they might not.

Edit: an index could relate to a group of credentials or something else entirely.

But it's probably usually clear from context, so might be fine.

It's commented in the example code and one would have to extract the index from the credential (or store it) under normal circumstances.

[cycraig]

Reverted to revoke_credentials for now until consensus can be reached. Should have been done in a different PR regardless.