feat: implement unified asset delta

[PhilippGackstatter]

Unifies the fungible and non-fungible asset delta tracking inside the kernel into a single asset delta. add_asset / remove_asset route every asset (regardless of composition) into one account_delta::update_asset procedure that combines the incoming delta with the current delta. The main benefit is that we now have one logic that handles both fungible and non-fungible assets, and should also support custom assets (as long as they implement certain APIs like merge, split and compare).

The initial idea for the asset delta is described in the OP in #2630, but was changed to a different approach during the PR review.

The delta now tracks a link map with entries:

[ASSET_KEY, INITIAL_ASSET_VALUE, FINAL_ASSET_VALUE]

Similarly, the delta is computed by computing the diff between init and final. This requires that we can order any assets that do NOT use AssetComposition::None, which we require with asset::lt. That way, we can figure out which asset is "greater" and compute diff = greater - lesser as well as whether it was removed (final less than init) or added (final greater than init).

Only asset::lt is required rather than a more general asset::compare. The main reason is that equality tests are handled by the kernel itself using word::test_eq, which would only leave lt and gt to be implemented by compare, and to avoid explaining this subtlety, only lt is required. Since this is all kernel-internal for now, we can easily make changes to this in the future, before we formalize support for custom assets.

The delta commits to the list of added assets, followed by a trailer and then the list of removed assets, followed by a trailer (Option 2 mentioned in #2630 but with an optimization).

Look-ahead: The asset patch commitment can iterate the same asset list link map to figure out if an asset has changed (init != final) and commit to the final asset value.

Follow-up:

• Refactor internal structure of AccountVaultDelta (can only be done after tx kernel commits to patches instead of deltas).
• Rename account_delta module to account_patch and similar things. Likely makes more sense going forward.

closes #2630

[PhilippGackstatter]

FYI: Updated the PR description to describe the new approach.

[bobbinth]

Looks good! Thank you! I left some comments inline - but they are mostly non-blocking.

One thing that would be good to find out is how the number of transaction cycles has changed after this PR. Probably worth re-running the benchmarks for this.

[PhilippGackstatter]

One thing that would be good to find out is how the number of transaction cycles has changed after this PR. Probably worth re-running the benchmarks for this.

Sure!
Cycle benchmarks against next (commit: 5320982). Committed in 9787c90.
Cycle benchmarks against this PR. Committed in 28a4c6c. This shows the diff between next and this PR.

Essentially, the new code takes ~300 cycles more in both the single and two P2ID consumption case. So it does not seem to scale with the number of assets. (Edit: Actually, the benchmarks I'm looking at compute the delta twice, so the diff shows as doubled - so comparing prev and new compute_delta_commitment should have a diff of ~150 cycles).

[mmagician]

LGTM with minor nits and some questions, but nothing blocking so feel free to merge when ready!