feat: Update SubmitProvenTransaction RPC with tx replay data

[sergerad]

Context

As part of the guardrails we are adding to the overall network, we want to be able to perform re-execution of proven transactions when they are submitted to the RPC via the SubmitProvenTransaction endpoint.

Relates to #613.

Changes

• Update SubmitProvenTransaction endpoint to take an optional binary encoded TransactionInputs.
• Update the RPC server's submit_proven_transaction() function to perform re-execution of transactions when the optional TransactionInputs is provided.
• Update ntx builder to submit proven transactions via RPC rather than block producer to allow for validation.

[bobbinth]

Before we start the implementation, would be good to describe the overall architecture. For example, it is not clear to me yet at which point it is best to do the verification and whether it will be done inside our current components or delegated to some new component. At the high level, I can see 3 separate approaches to this:

1. Everything happens in the RPC component. That is, the RPC component decodes the reply data, re-executes the transaction, stores the reply data somewhere (e.g., a separate database or my in our existing store), and from the point on, everything else works as it does now.
2. The replay data travels through our existing "pipeline" - i.e., the RPC component re-executes the transaction, but then passes the data to the block producer, which includes it with the block that gets submitted to the store.
3. There is a new component that the RPC sends the transaction to. This component re-executes the transaction, signs it, and send the signed transaction back to the RPC. The RPC then send the transaction with the signatures to the block producer.

We should think through pros/cons of the above as they will result in different implementation complexity but also will allows to provide different "features".

[sergerad]

@bobbinth

1. Do we want this to be blocking as it is now?
2. Do we want this to return an error if it fails? Or just log like it does now?

[drahnr]

Since this is opt in for debugging only, we probably want to create bounded queue but do the re-execution async. This implies it's not going to block by default, but will eventually if we're under high load, mostly to avoid OOM as it would occur in the unbounded channel scenario. This would hint at 2. being logging only.

[sergerad]

This re-execution logic will move to the validator component and this RPC stack will talk to that via gRPC.

Having said that, I think the bounded queue and async processing logic would be the same for this PR and the followup work. Its just a question of what we want to put into this PR for now.

[sergerad]

I will need 0xMiden/miden-client#1382 to be completed before I can update client and integration tests to validate the changes in this PR.

But in the meantime I will prepare this for merge because the new codepath cannot be triggered without the client changes anyway.

[sergerad]

I have run integration tests to validate the new codepath and it seems innocuous 👍

[bobbinth]

Looks good! Thank you! I left some comments inline - but most of them are for the future.