Replace fee faucet ID with fee asset key

[PhilippGackstatter]

After #2939, the TX executor assumes the callback flag of the fee asset is set to disabled and the composition of the asset is AssetComposition::Fungible. Since users only provide the fee faucet ID when constructing FeeParameters, this set of requirements is never explicitly checked, which is error-prone. Users could be providing the account ID of a faucet that issues non-fungible, callback-enabled assets, and so the fee asset essentially does not exist in practice.

Consider changing FeeParameters::fee_faucet_id to a fee_asset_key: AssetVaultKey and checking the above requirements in the constructor instead, to provide feedback to the caller.

The tx kernel should likely also take the whole asset key as an input (provided as advice) rather than just the faucet ID, which is less error-prone.

Brought up by @mmagician in #2939 (comment).

[bobbinth]

Somewhat related to this: right now AssetVaultKey is always serialized as 4 field element though for fungible assets we enforce the the AssetId portion is always zeros. I think we can improve the serialization to be just 2 field elements (i.e., 128 bytes).

It may also make sense to introduce a newtype for this - e.g., FungibleAssetVaultKey (which would basically only contain the 2 meaningful elements of the AssetVaultKey) - though, I can also see arguments against this.

Separately, it may make sense to rename some of these structs. Specifically, I think a more natural name for what we call AssetVaultKey may be AssetId - and then we'll need to find some other name for the current AssetId struct. One motivation for this is that for external users AssetId would make more sense than AssetVaultKey as a unique identifier of an asset - e.g., see an example of the JSON in #2919 (comment) where asset would probably be our current AssetVaultKey (rather than faucet ID).

[PhilippGackstatter]

I think we could optimize the vault key serialization as you mention. For completeness, next to the faucet ID we also need to serialize the asset metadata (callback flag, composition) still. So the only thing we can omit is the AssetId.

I like FungibleAssetVaultKey, as I think this could work well in concert with #2632. Described this here: #2939 (comment).

I also like the idea of using AssetId as the identifier for assets as a whole. This makes the three main building blocks of Miden (accounts, notes, assets) all be identified by an ID (AccountId, NoteId, AssetId).

Since the current asset ID determines if two assets will compose (in addition to the composition flag), composition_id would be one option. Other options could be asset_serial or asset_fingerprint, but having names that are close in meaning between AssetComposition and AssetCompositionId seems good.