The fees are currently calculated as a sum of the L1 fee and the L2 fee
where the L1 fee is the approximate cost of the batch submission of the
transaction (L1 gas price * L1 gas used) and the L2 fee is the
approximate cost of the execution on L2 taking into account congestion
(L2 gas price * L2 gas limit).

When either the L1 or L2 gas price is volatile, it can result in the
quote that the user receives from `eth_estimateGas` to be rejected
as the fee that the Sequencer is expecting has gone up.

This PR adds logic to set a buffer in either direction of the current
price that will allow the sequencer to still accept transactions within.

Two new config options are added:

- `--rollup.feethresholddown` or `ROLLUP_FEE_THRESHOLD_DOWN`
- `--rollup.feethresholdup` or `ROLLUP_FEE_THRESHOLD_UP`

Note that these config options are only useful for when running
in Sequencer mode, they are not useful for replicas/verifiers.
This is because the Sequencer is the only write node in the network.

These config options are interpreted as floating point numbers and are
multiplied against the current fee that the sequencer is expecting.
To allow for a downward buffer of 10% and an upward buffer of 100%,
use the options:

- `ROLLUP_FEE_THRESHOLD_DOWN=0.9`
- `ROLLUP_FEE_THRESHOLD_UP=2`

This will allow for slight fee volatility downwards and prevent users
from excessively overpaying on fees accidentally.

This is a UX and profit tradeoff for the sequencer and can be exploited
by bots. If bots are consistently taking advantage of this, the max
threshold down will have to be calibrated to what the normal fee is
today.

Both config options are sanity checked in the `SyncService` constructor
and will result in errors if they are bad. The threshold down must
be less than 1 and the threshold up must be greater than 1.