Migrate to miden-vm v0.10

[bobbinth]

This PR migrates miden-base crates to miden-vm v0.10.

Here is a high-level summary of changes:

miden-objects:

• AccountCode, NoteScript, and TransactionScript are now backed by MastForest (i.e., compiled MASM code) and so, no longer need an assembler to be instantiated. I did add compile() constructors to these so that they can be instantiated from source code as well.
• ExecutedTransaction and TransactionWitness no longer need to have the Program field. This is because the program executed is the same for all transactions (it is the main procedure of the transaction kernel).
• Removed PreparedTransaction as it is no longer needed.

miden-lib

• All source MASM code is now compiled into MAST at build time. So, once we build the kernel, the library, and the note scripts, there is no need to use assembler for them again.
• MASM modules under asm/miden/kernels/tx have been moved to asm/kernels/transaction/lib to indicate that these modules are relevant to the transaction kernel and not miden-lib itself. There were a couple of procedures that I had to duplicate because of this move. We'll figure out how to avoid this duplication in a future PR.
• I inserted dummy instructions push.<random value> drop next to some advice injectors to make MAST nodes hash to unique values. This is a temporary workaround to avoid collisions of MAST nodes which differ only in their use of decorators. I'll create an issue in miden-vm for how this should be resolved properly.

miden-tx

• TransactionCompiler has been replaced with TransactionMastStore. I haven't deleted yet the TransactionCompiler file because some logic still needs to be transferred to the TransactionMastStore. And generally, I need to document TransactionMastStore and maybe refactor it a bit.
• TransactionExecutor now loads note/tx script into the MAST store before executing a transaction. The MAST store is then passed to the TransactionHost which serves requests from the VM for programs matching a given MAST root. TransactionProver works in a similar way.
• I removed DataStore::get_account_code() method as we get all relevant info from DataStore::get_transaction_inputs() now.

bench-tx

• I disabled this crate for now as it relies on the removed PreparedTransaction struct. This will need to be refactored in a subsequent PR.

[bobbinth]

This is not yet fully finished, but I'm opening it up for review because I got the p2id_script_multiple_assets test to pass and so things are mostly working though I do need to clean things up quite a bit and also refactor a few things in miden-tx. See PR description for the current state of things.

[bobbinth]

I'm marking this as "ready for review" as I think most of the migration is complete. A few notes:

1. All integration tests are currently passing locally - but I've disabled all "kernel tests" because the structure there needs to be updated. It is possible that once we enable kernel tests, we'll discover some additional bugs, but given that all integration tests are passing, I think the bugs should be fairly small. It may make sense to rebase #807 from this PR, get the kernel tests passing, and only after that merge this PR. @igamigo - could you take a look at this?
2. Some of the integration tests are timing out in the CI because execution/proving times have roughly doubled. This is because we've disabled inlining in current assembler. I'm hoping that this is going to be partially fixed by 0xPolygonMiden/miden-vm#1454, but I think this degradation won't go away until we bring back full procedure inlining.
3. Would be great to confirm the above by running transaction benchmarks. But I've disabled bench-tx crate for now. @Fumuran - could you open a PR based on this one to re-enable it? Once this is done, we can see how cycle counts have changed as compared to what we had before.

A few other things:

• With the removal of TransactionCompiler, we've lost one nice feature: performing "soft checks" on whether a given note/tx script can be executed against an account. I'll create an issue describing how to bring this functionality back.
• I still need to document TransactionMastStore - but this should be pretty straight-forward. One idea I tried to implement is trying to combine TransactionMastStore and DataStore into a single interface - but this turned out to be a much bigger change, and I decided to leave it for future PRs.
• I still need to create an issue in the miden-vm repo about how to properly handle collision between MAST nodes which differ only in their use of decorators.

[plafer]

LGTM - at least the parts that touch the changes to the VM

[bobbinth]

LGTM - at least the parts that touch the changes to the VM

btw, I ended up wrapping all MastForests in Arc (e.g., here). I think we can do something similar for Library and Program structs in miden-vm (could be just a small PR before we do some deeper refactorings).

[phklive]

LGTM, focused mainly on the MASM changes considering that @plafer focused on the VM side.

All tests passed locally, tests in CI are failing because of timeout ( should be fixed by updating the nextest timeout rules):

Increase of 121.39% in testing time with the new assembler or we could say a decrease of 54.84% in performance.

We should run make lint to make sure we pass the fmt ci checks.

Left a few simple questions.

[phklive]

Why did we need to copy paste some code from the Kernel?

[phklive]

@bobbinth I have tried reading about it throughout the repo (issues, pr's, discussions) could you clarify what is a "decorator" in the context of MASM and why we need them?

[bobbinth]

@bobbinth I have tried reading about it throughout the repo (issues, pr's, discussions) could you clarify what is a "decorator" in the context of MASM and why we need them?

As discussed offline, decorators are special instructions which do not affect the internal VM state (i.e., memory or stack). They are used primarily for two purposes:

1. Update the state of the advice provider (i.e., advice injectors).
2. Annotate VM operations, mostly for debugging purposes (e.g., the debug decorator).