Add time to mine context to user operations in the pool
Track the number of user operations that are currently "candidates" i.e. their fees are high enough to be included
Track the amount of time/blocks an operation spends in the "candidate" state
Add histogram for time/blocks to mine
Re-use the expiry loop into a maintenance loop to limit O(n) operations
Limitation: time to mine has a granularity of 1(s) so on fast block networks (Arbitrum) we don't have the level of granularity needed, however we do have N blocks.
Open question: should we switch candidate time to be based on system time and not block time?
Closes #319
Proposed Changes