Implement `TryFrom<PartialAccount>` for standard components

[igamigo]

Standard components implement TryFrom<Account> to ease the extraction of components from an account.

As it is right now, some standard components do not require the full account for this and could just implement conversions from storage headers or any related struct (like PartialAccount). This applies to any component that does not use storage maps, as AccountStorageHeader will have all the necessary storage slots data (ie, all the value slots).

This would allow users to easily extract things like token metadata from the network without having to download the full Account, which may have extra roundtrips and data (right now, you can get the header storage with a single GetAccount call). Of course, this is doable right now but slots need to be read and parsed manually.

[PhilippGackstatter]

Generally agreed. Does the conversion actually consume the PartialAccount or wouldn't it rather just read the relevant data without consuming it, so TryFrom<&PartialAccount>? If you need to read n components from a partial account, then this avoids having to clone it n times.

It would be great if we could standardize this via a trait, which I think was brought up a couple of times now, that each concrete account component implements. That way we wouldn't have the current inconsistent API where some components are reconstructable, because we needed it at some point, and some others aren't.

The BasicFungibleFaucet::try_from_interface is a good example for what the general API could look like:

fn try_from_interface(
    interface: AccountInterface,
    storage: &AccountStorage,
) -> Result<Self, AccountError>;

The issue is that this requires a full account storage and we'd need a second method that takes just &PartialStorage. I don't like the idea of two methods, i.e. these force every account component to re-implement the reconstruction logic or implement the abstraction over storage. Instead, this is something we should provide. Generally, PartialStorage is powerful enough to represent a full AccountStorage, and so it seems there is an opportunity for an account storage abstraction. I can think of two approaches.

Refactor storage representation

We refactor AccountStorage and of PartialStorage, so that we can impl AsRef<PartialStorage> for AccountStorage. Then we can write the trait like this:

pub trait AccountComponentInterface: Into<AccountComponent> {
    fn try_from_interface(
        interface: AccountInterface,
        storage: impl AsRef<PartialStorage>,
    ) -> Result<Self, AccountError>;
}

I haven't looked deep enough into it yet to say whether this can be done reasonably well.

Add a storage trait

Another possibility that doesn't require a storage refactor is to have an AccountStorageInterface trait, which may look something like this:

pub trait AccountStorageInterface {
    pub fn get_item(
        &self,
        slot_name: &StorageSlotName,
    ) -> Result<Word, AccountError>;

    pub fn get_map_item(
        &self,
        slot_name: &StorageSlotName,
        key: Word,
    ) -> Result<Word, AccountError>;
}

pub trait AccountComponentInterface: Into<AccountComponent> {
    fn try_from_interface(
        interface: AccountInterface,
        storage: &impl AccountStorageInterface,
    ) -> Result<Self, AccountError>;
}

We should be able to implement this for PartialStorage. If an item isn't present, then it would return an error.

---

One difficulty with both approaches is that a map item that is not tracked by partial storage, but is actually present in full storage, would probably return the same error as an actually missing item. This makes debugging fairly annoying, but not sure we can solve this.

I prefer the first approach if it is possible to do well, because it avoids introducing another trait.

I'm not yet sure if we should force all components to implement AccountComponentInterface or not. If we want to, can essentially require this by changing the AccountBuilder::with_component API to take impl AccountComponentInterface. Also, the AccountComponentInterface could have a few other methods, the above is kept minimal for the purpose of this issue.

Just noting it down here: Once we have this trait or AccountAuthComponentInterface, we should consider replacing the static set of auth methods in AuthMethod with impl AccountAuthComponentInterface, e.g. in create_basic_fungible_faucet. That would allow a user to provide an arbitrary auth method.