Refactor native asset delta, composition and validation #2629
Description
The main use of AccountType::{FungibleFaucet, NonFungibleFaucet} is describe 1) how assets are structured and 2) how they compose (e.g. fungible_asset(amount=20) + fungible_asset(amount=30) = fungible_asset(amount=50)).
Both of these can be done differently now.
- How assets are structured:
- The asset delta relies on this, but can be unified. Instead of individual fungible and non-fungible asset deltas, we handle assets uniformly and already have the delta setup for later custom assets.
- Validation: Validation can be moved to
miden::standards::{fungible_asset, non_fungible_asset}.
- How assets compose can be described at the asset key level instead of at the account ID.
Each of these points is described in more detail in a dedicated issue.
Finally, the distinction between whether regular accounts are immutable or not will be decided at the interface level.
Consequently, after these refactors we can fully remove AccountType in its current form (and rename AccountStorageMode to AccountType to make it consistent with NoteType).
The ideal order of implementation for the issues is probably:
- Delta refactor
- Composition enum
- Move validation