Replace ClientMap with Client in Account

[cycraig]

Description of change

Refactors the Account to use a single Client rather than a ClientMap, since each Account only manages a single identity (which can only live on a single network/Tangle). This change slightly simplifies the Account and AccountBuilder.

This also means an Account will not be able to create both mainnet and devnet identities by default, which was a side-effect of ClientMap automatically creating clients for both those networks by default.

A minor downside of this refactor is that AccountSetup always needs a Client on creation, which is an async operation. Previously the Clients were constructed lazily by the ClientMap. However, this change only affects our internal tests as far as I can see.

Minor change: the private Tangle examples now set the primary_node rather than just node since the behaviour for node differs between Rust and Wasm: on Wasm the node is considered "synchronised", while in Rust the node is considered "un-synchronised" until a background task (from iota-client) marks it as "synchronised". This causes the Rust private Tangle examples to throw an error (when pointing to a running private Tangle or devnet or mainnet) since it considers all nodes to be "un-synchronised". We use primary_node since it bypasses this check.

Added

• Add AccountBuilder::client_builder (in addition to AccountBuilder::client to allow building a single Client or sharing an existing Arc<Client>).

Changed

• Update AccountBuilder::client to take Arc<Client> instead of a ClientBuilder closure.
• Update AccountBuilder::create_identity to use the network from the configured Client rather than IdentitySetup.
• Update AccountBuilder::load_identity to throw an error if the DID network does not match the Client network, which would throw an error when publishing the document anyway.
• Update Client::publish_document to throw an error if the DID network differs from the Client network.
• Update Client::publish_diff to throw an error if the DID network differs from the Client network.

Removed

• Remove Account::set_client.
• Remove IdentitySetup::network.

Links to any relevant issues

Fixes issue #531

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

All tests and 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]

Thanks for the changes, looks good overall. I'm wondering whether we still need IdentitySetup::network, though.

[cycraig]

Should we expose the Client in the Account by adding an Account::client() method?

[PhilippGackstatter]

Should we expose the Client in the Account by adding an Account::client() method?

What is the advantage of exposing the client? The network can be obtained through account.did().network() so I guess it's not because of that?

[PhilippGackstatter]

Thanks for the changes! Looks good to me.

[cycraig]

Should we expose the Client in the Account by adding an Account::client() method?

What is the advantage of exposing the client? The network can be obtained through account.did().network() so I guess it's not because of that?

To be able to access the Client to pass it to e.g. another AccountBuilder or Resolver is what I had in mind. I don't think it's necessary at this point so I'll leave the API as-is.

[PhilippGackstatter]

To be able to access the Client to pass it to e.g. another AccountBuilder or Resolver is what I had in mind. I don't think it's necessary at this point so I'll leave the API as-is.

I see, that makes sense. In #574 a getter for the storage was added, so maybe something similar will be required for the client as well.