feat(validator): FPI support in data store

[sergerad]

Context

The Validator's TransactionInputsDataStore does not handle foreign accounts for the purposes of the following functions of DataStore trait:

• get_foreign_account_inputs()
• get_foreign_account_inputs()
• get_vault_asset_witnesses()

NOTE: This will remain in draft until miden-base has the TransactionIniputs::read_foreign_account_inputs() functionality merged into next.

A followup PR will be made to add similar functionality to the NtxDataStore.

Relates to #1387 and #1305.

Changes

• Update TransactionInputsDataStore to handle foreign accounts through self.tx_inputs.

[Mirko-von-Leipzig]

I realized recently that we should probably be using std::futures::ready instead of async move to create futures for sync code. Though the difference is really just when the bulk of the work gets done.

// This
return std::futures::ready(x);

// Instead of this
async move {
    // Only sync code
    return x;
}

[bobbinth]

Looks good! Thank you! I left just one small nit inline.

Also, would be good to get a review from @igamigo. Maybe we can run client integration tests against this branch to confirm that transactions that do FPI calls can indeed be accepted by the node.

[sergerad]

Maybe we can run client integration tests against this branch to confirm that transactions that do FPI calls can indeed be accepted by the node.

I tried running the tests from miden-client next against this but they are not compatible. That is after I merged miden-node next into this branch.

[PhilippGackstatter]

The native account's witnesses are handled just like the ones for foreign accounts, i.e. they are added to the advice inputs on lazy loading, but not to the PartialVault. Any asset witnesses that are present in the partial vault at the beginning are also added to the advice inputs.

So, the advice inputs contain both the pre-provided asset witnesses and those fetched during lazy loading, and so we should read from the advice inputs and not from the partial vault.

The need for this should go away with 0xMiden/miden-base#2298 completely, at which point this could be replaced with unimplemented!.

Because of these subtle differences, I still think it would be good to add a test for this, e.g. one that has an FPI call, reads a storage map item lazily and has input notes with some assets, so the pre-fetch is executed.

And then all of these annoying details should be abstracted away once we have a re-execution API exposed in base directly: 0xMiden/miden-base#2293.