Allow validator to receive and directly incorporate bundles of transactions

[m4ksio]

The SEI MEV Proposal aims to add Maximal Extractable Value support to the SEI network.

The background, motivation, and detailed technical choices are documented in the corresponding SIP document (work in progress). This PR description focuses solely on documenting the code implementation. While comments and questions are essential to our community-driven process and always welcome, any non-trivial discussions not directly related to the code should take place in the SIP.

A Brief Background

This MEV proposal adds support for transaction bundling—a mechanism where multiple transactions are included in a block in a specific order. The technique is widely used in the industry (see for example Jito on Solana) and enables various MEV approaches. These bundled transactions are ordinary transactions that must be properly signed, pay fees, and execute in the same environment. Blocks created with bundling remain ordinary blocks, with no changes to blockchain rules or to transaction and block data structures.

High-Level Overview

MEV is disabled by default. When enabled, a validator connects to a bundle-server and polls for new bundles. As bundles arrive, they are stored in a keeper. During block production, the system queries the keeper for bundles at the current height and includes them in the block.

Trust and Impact

MEV and bundle formation is by its nature an off-chain activity. Validators must trust their chosen bundle-server to supply the most valuable bundles and pay out appropriate rewards.

Even without MEV, the block proposer has full discretion over which transactions to include or exclude.

Dependencies

• Drop validating if record set was constructed from original transactions  sei-tendermint#278 SEI maintains its own fork of Tendermint, now called CometBFT. To properly support MEV block formation, Tendermint needs to remove a check for transactions that are added or removed during the block building process. While this might sound concerning, it affects only an internal Tendermint code path. Due to the nature of blockchain itself, the transactions supplied as "original" (using Tendermint's terminology) are always subjective. Additionally, this check has already been removed from upstream code - https://github.com/cometbft/cometbft/blob/main/types/tx.go#L117 - so we consider this change to be a backport. We expect this to be merged into upstream sei-chain/sei-tendermint - but for now, it's replacing original dependency

• Protobufs. Validators pull bundles from the bundle-server. By design, this is an external component that we keep separate using gRPC/protobuf communication. The protocol should become part of the SEI standard. Due to the complexity of compiling and including protobufs from the SEI repository, we've added them to a separate repository. This allows bundle-server development to depend on this simple interface instead of the entire SEI repo. However, this is primarily an implementation detail that remains open for discussion.
  https://github.com/SiloMEV/silo-mev-protobuf-go which uses protobuf files from https://github.com/SiloMEV/silo-mev-protobuf