fix(jito_rpc): makes jito bundle atomic

[0xzrf]

Summery

Simulates each transaction sent in the sendBundle rpc method and early returns if any of them fail.

Changes

• Adds an iterator inside the SurfpoolJitoRpc::send_bundle function before sending transactions
• Adds test to check if it returns the right error message

Note

This might not entirely replicate jito bundles. But since it's majorly used for testing purposes, it works well to say that the bundle is atomic

Closes #594

[MicaiahReid]

Sadly this won't cut it. A jito bundle is likely to be a set of transactions that build off each other. For example:

1. Transaction 1 - Create token account, fund it
2. Transaction 2 - Put token from token account into escrow

In this case, since we're just simulating one after the other, tx 1 would succeed for simulation, and tx 2 would fail, because it depends on tx 1 being in affect.

Even a diferent loop like:

1. Simulate tx 1
2. Execute tx 1
3. Simulate tx 2
4. Execute tx 2
5. etc...

Wouldn't work, because if there's a third tx that will always fail, txs 1 + 2 have made changes to the VM while tx 3 fails, so this is no longer atomic:

1. Simulate tx 1
2. Execute tx 1 (changes VM)
3. Simulate tx 2
4. Execute tx 2 (changes VM)
5. Simulate tx 3 -> fails, return error

This case shows that even though a transaction in the bundle fails, some of the transactions still make changes to the vm, breaking atomicity.

---

I don't know how much of the plumbing is in place to do this from the jito RPC methods, but take a look at how we're executing the instruction profiles.

We essentially clone the whole VM state so we have a disposable sandbox where we can make changes to the cloned VM without changing the real VM.

We execute all transactions against the cloned VM, and if none of them fail, we can be confident that the transactions won't fail on the source VM.

I think we'll have to do the same here

[0xzrf]

Hey @MicaiahReid
Added the disposable vm as suggested, and added some tests for the same

I'm wondering what should happen with the real svm state?

1. Should we execute txns as usual(Time consuming, can miss the block)
2. Just Copy the account state from the vm to the real svm

What're your thoughts on it?

[MicaiahReid]

I love the idea of taking the cloned VM and applying the changes onto the real VM, but I don't think it'll work here.

When the vm is cloned for profiling, we're making sure that geyser events + account WS updates aren't being propagated. So we need to be sure to actually execute the changes against the real VM so those updates get sent

[0xzrf]

Hey @MicaiahReid
Could you review this PR?
Thanks.