feat: per-address gas limit feature

[fahimahmedx]

Summary

Per-address gas limit feature summary — We use a standard token bucket algorithm to rate limit transaction inclusion from senders. Each sender is allocated a gas bucket, and each transaction they send needs to take from that bucket, whether the transaction reverts or not. The buckets refill a little bit every block. If a sender doesn't have sufficient gas for a transaction, then their transaction gets delayed until their bucket refills.

This PR does the following:

• implements this gas-limiter feature originally from op-rbuilder, integrating the gas_limiter module from op-rbuilder
• implements filters field to AppendOrders, allowing custom boolean functions to be used for filtering out transactions.
• integrates the gas_limiter module to be used as a filter in the AppendOrders step.

Todo:

• Put gas_limit in pool/filters folder.
• "Think about an interface design that optionally allows devs to add pre/post job logic, while still allowing the minimalistic syntax that we have right now."
• "Try to find an elegant way to initialize the filter-specific metrics scope at runtime in the setup function. We might need to change the filter interface if there is no clean way of doing it."

[karim-agha]

The code looks good and clean, good job. There are few design choices you need to make here.

Also please move this module under /pool/filters/

[karim-agha]

This should be #[derive(MetricsSet)]

See:

rblib/src/steps/revert.rs

Line 170 in 592608a

#[derive(MetricsSet)]

Pipeline steps learn about the name of their scope when the pipeline is instantiated. So far, the pattern that has emerged is that metrics are initialized (::with_scope(..)) in Step::setup. Try to find an elegant way to initialize the filter-specific metrics scope at runtime in the setup function. We might need to change the filter interface if there is no clean way of doing it.

[karim-agha]

Alright... we're seeing an emerging pattern here. Maybe more filters will need to have some logic that kicks in before or after a payload job.

Try to think about an interface design that optionally allows devs to add pre/post job logic, while still allowing the minimalistic syntax that we have right now.

[karim-agha]

nit, maybe this alternative shape of the data structure?

enum AddressGasLimiter {
   Disabled,
   Enabled { config, address_buckets, metrics }
}