feat: implement surfnet_sendJitoBundle RPC method

[MunirG05]

This PR introduces bundle-like simulation support inspired by Jito’s bundle execution model.
The goal is to allow developers to test complex MEV or multi-transaction workflows locally—sequential, atomic execution of up to 5 transactions as a “bundle".

In regards to this Discord Thread.

[lgalabru]

Apologies for the latency on this PR @MunirG05!
I was able to get some feedback from someone at Jito, here's what I got:

Yeah! So the main thing here is that Jito-Solana’s BundleStage accepts Bundles as a group of 5 txs which can be from any signer, exclude vote accounts, and execute atomically. there’s some other subtleties around their internal execution. Wonder if that could be done in litesvm. also they need to go to our block engine with a tip to be forwarded as a bundle.
It’s not so different from normal transaction submission but definitely could be useful for your users to play with without having to use us on testnet/mainnet.
Regarding the adversarial MEV… that’s hard to simulate, it’s one of those things that only really comes up in the wild depending on the tx supply chain and malicious validators. Like you could simulate a frontrun or sandwich I guess but not sure how valuable that is

What do you think?

[MunirG05]

Hi @lgalabru,
Much thanks for getting the folks at Jito involved!
I personally think MEV itself is a varied thing, you don't really need to be competing with others to be needing MEV executors, for example, Arbitrage itself could be tested for accuracy or correct execution locally by simulating the required conditions for execution or what not, instead of having to wait for mainnet to have the opportunity to test code that has the potential to break.

As for whether it's implementable in LiteSVM, in my personal opinion, it's nothing too fancy, there are just certain rules that need to be followed during execution of said transactions,

1. Is the simulation of all the transactions in a sequential manner, meaning the state changes of the previous transactions are taken into account during the execution of the next, if all pass we go to the execution stage
2. We process the the transactions in the given sequence IF one fails we have to revert the SVM state to whatever it was before or find some way to rollback the transactions only.
3. There is a rule that they must at least lock one tip account, that is easy as well.

In my workflow, even my flawed approach has proved to be useful, but if it were to be improved, it would definitely prove to be an extremely useful feature, even if it were only used by a subset of users.