Closes: #158
Added a simple algorithm to help prevent posting when eth transaction fees are high.

You can visualize how it works by using the simulator:

cargo run --release --bin fee_algo_simulation   

The simulator lets you see how much a transaction with N_BLOBS would have cost at different times in the past. The blob transaction fee is calculated like this:

21,000 * (base_fee + reward) + N_BLOBS * BLOB_SIZE * base_blob_fee

You’ll see three fee values: the current fee, the short-term fee, and the long-term fee.

Right now, “short-term” is set to the last 5 minutes, and “long-term” covers the past 3 hours, but you can adjust these settings.

We decide it’s a good time to send a transaction when the short_term_fee drops below long_term_fee * max_fee_multiplier. In the simulator, this is shown with green shaded areas.

The max_fee_multiplier starts at start_max_fee_multiplier (eg. 0.8) and can go up to end_max_fee_multiplier (e.g. 1.7). As we fall behind on posting L2 blocks, the multiplier linearly increases towards the maximum (when we've reached max_l2_blocks_behind).

If the multiplier hits the max value, the algorithm turns off, and we’ll accept any fee.

On the flip side, if the fee goes below always_acceptable_fee, we’ll disable the algorithm because it’s better to stay up-to-date than to save just a tiny bit of eth.

All of the above-mentioned values can be tweaked in the simulator:

This feature has been running on the testnet and is showing promising results, as you can see from the grafana graphs below:

At around 6:10 the prices start to rise, we wait them out and continue posting after they settle back down.

This PR also keeps track of how many L2 blocks we’re behind. This helps both for monitoring and for the algorithm itself. It’s calculated by:

• Determining the starting height of the oldest bundle we should post to L1
• If we’re not posting anything (meaning a bundle is still being optimized), we use the last bundled height plus one.