Refactor the Account state

[PhilippGackstatter]

Description of change

This PR implements part of what was discussed in #433, namely the refactoring of the state representation in the Account.

The main changes:

• Remove the event & commit system of the account and use a dual-document state. One document, the current on-tangle representation, is cached locally in storage, while all updates are applied to an in-memory document that is part of the account's state.
• Remove the parts of the IdentityState that were essentially duplicates of the IotaDocument, e.g. TinyMethod, TinyService, etc. The state type now holds a document directly and only adds some state on top.
• Remove diff and int generation from the state, and replace it with a single generation field. These generations are used for detecting whether an identity is fresh (generation == 0) and used in the location of keys to differentiate between keys with the same fragment, that were created in different generations.
  • The current solution is temporary until Enable moving keys stronghold.rs#283 lands, which will allow us to implement key locations based on the public key and the fragment, and remove all extra state such as generations.
  • Once the above is implemented, the IdentityState will be removed completely and the account can hold the IotaDocument directly.
  • In anticipation of the complete removal of IdentityState, the chain state was factored out of that type into a dedicated ChainState type. This keeps track of the previous integration and diff chain message id, which is required state for implementing automatic int or diff publishing.
  • The check for whether an identity is new is based on whether the previous integration message id is MessageId::null(), since the generation is anticipated to be removed in future updates.
• Introduce MethodRelationship next to MethodScope, in order to disallow attaching relationships to a method with MethodScope::VerificationMethod.

This PR does not address:

• Moving the existence and duplication checks for insertion and removal of methods to the IotaDocument.
• Purging/Deleting keys in storage, this will be addressed with the key location refactor, although deleting keys as soon as they are no longer needed is slightly risky (if an update isn't included in the tangle) and hasn't been addressed in the account so far, so this might need some discussion.
• Saving every update as a diff to storage. The state is currently only saved to storage on identity creation and after a successful publication. Dropping the account, with several unpublished updates in-memory, would get rid of these updates. A future PR will implement storing the diffs of each update in storage for later publication, or possible re-application on a changed base document (e.g. one that was resolved/synced from the tangle). One of the light blockers on including it in this PR, is that diffing metadata is currently hard, because identity_iota::did::doc::properties::Properties does not implement Diff. [Task] Implement metadata structures #486 will presumably make diffing metadata easier than it currently is, which should make it easier to implement this feature.

Since this is a large PR, and anyone would like to focus on a specific area of it, my suggestion would be to carefully review the publication logic around whether to publish as an integration or diff update, and whether the previous_message_id is always set correctly.

Finally, while this PR does not address every part of the planned refactor, it should be good enough to get started with the low-level access API implementation and the synchronization.

Links to any relevant issues

#433

Type of change

Add an x to the boxes that are relevant to your changes.

• 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

Several tests were added or extended, namely the updates test, Publish tests, and adding or detaching relationships on an IotaDocument.

Change checklist

Add an x to the boxes that are relevant to your changes.

• 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]

Can't we store the altered document instead of the diffs?

That should also work, good idea!

I didn't notice any glaring issues with setting the message ids

Main reason I'm confused is that I didn't find where the previous message ids were set in the current code, specifically for integration updates.

I addressed most comments, except for the attach_method_relationship discussion (which I'm thinking of pushing to a later PR, when also moving more checks to the lower level for remove_method and insert_method) and the publish type with the UPDATE_METHOD_TYPES which I still want to add, to reduce the number of cases that require integration updates. Will work on that on Monday (presumably).

[olivereanderson]

I like the smaller crate level Error introduced in this PR. In general I would prefer to always return a named error instead of using an alias for the entire Result which seems to be mostly the case in this crate, but that is something we can think about when we get round to refactoring more of our error handling.

[cycraig]

Looks good to me, thanks for the changes!

Minor comments. I could have missed something between all the changes to be honest.