I observed a very small savings from increasing the optimizer runs,
and no noticable impact on compile time

Although we're quite happy when the CTC gets cheaper, we want to know about it
and lock-in the savings.

Previously our gas specs have only printed the values they record,
without ensuring that the cost doesn't drift up over time. Adding expectApprox will allow these costs to decrease, but not increase.

Previously the sequencer would call the `syncBatchesToTip` method
as part of its `sequence()` loop. This commit removes that as the
call to `syncBatchesToTip` does nothing for the sequencer currently.
Syncing the batches would be useful for triggering reorgs, but
that functionality does not currently exist. It would be better to
remove this functionality for now as it could potentially interfere
with the locking mechanism introduced in
dfaa8fc20f586265f0a5c07ca76c6c793ba49157.

This will also reduce the amount of time the `txLock` is held, meaning
that less transactions sent via RPC will be blocked and held in memory
while waiting to execute.

to message-relayer and integration-tests

and remove SafeMath from 0.8 GasPriceOracle contract

as these serve as integration points for projects

as activated by default in 0.8

https://docs.soliditylang.org/en/v0.8.0/control-structures.html#checked-or-unchecked-arithmetic

Breaking change in v0.8.0

Have the ethers L2 context helper pass through the
new optimistic ethereum related fields

The response of the RPC endpoint `eth_getTransactionReceipt`
will now return 4 new fields.

- `l1GasPrice`
- `l1GasUsed`
- `l1Fee`
- `l1FeeScalar`

These fields are added to the database as part of the receipt
itself. This means that it is a consensus change as the
serialization of the receipt has been updated. This impacts
the blockhash because the block header commits to a merkle root
of all of the receipts in the block.

Each of the new fields on the receipt exist in the state but
would require an archive node to query for as the values can
change over time.

Manually handle locking and unlocking to prevent race conditions
if the fee logic. The case that needs to be handled is as follows:
a `gas-oracle` transaction updates the gas price after an queue
origin sequencer tx is sent via RPC and already goes through the
fee check. This would cause the transaction to be accepted and then
fail during the state transition. This is bad because we do not
have logic to hold on to the failed transaction to execute later,
which is what the user would expect when sending transactions to
L1. All transactions that are sent to the miner *must* be valid
transactions.

Reduce the number of requests sent by the message-relayer
in the docker setup to make the logs better