It was being deployed with the implementation address
of the `L2OutputOracle` instead of the proxy. This
was preventing output commitments to actually be posted.

* op-batcher: Enable optional pprof server

* op-proposer: Enable optional pprof server

* op-node: Eanble optional pprof server
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* test(ctb): change gasLimit arg to uint256

* test(ctb): Set maximum diff fuzz gasLimit to 30MM

* test(ctb): Set maximum diff fuzz value to 120MM eth

* ctb: Address compiler warnings
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* ops: Use starting L1 Block for timestamp everywhere

This transitions the starting timestamp to a new flow. The L2 rollup
is anchored on a L1 block. The L2 genesis block & rollup config use
the timestamp of the L1 start block as the their time. Properly
threading this through the HH tasks is a little tricky but possible.
This is because we have two flows: creating a L1 network & placing
the rollup on that and creating a rollup on an existing L1 network
(like goerli). There is still a L1 starting time for the first flow.

This also fixes a circular dependcy that previously existed. The
starting timestamp was provided and served as the starting timestamp
for the L1 genesis & the "L2 Starting Time" in the L2 Output Oracle.
The actual L2 genesis & rollup start time were based on when the
Optimism Portal contract was deployed (after the L2 Output Oracle
contract must have been deployed). The rollup is resilient to being
started before contracts are fully deployed, so using a specific
L1 block as the start is the cleanest solution I have seen.

* Fix lint

* Update packages/contracts-bedrock/deploy-config/goerli.ts

* Add undefined checks to l1StartingBlockTag

* lint

* fix checks
Co-authored-by: Matthew Slipper <me@matthewslipper.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

contracts-bedrock: in place handling of immutables

This updates the hardhat task `genesis-l2` to handle
setting the immutables in the deployed bytecode. This
is necessary because the predeploys "live" in the L2
state and are not deployed. Any immutables must be manually
placed into the bytecode by looking at the compiler output
and then finding the offsets and slicing in the values.

A high level API is exposed for setting arbitrary immutables
with the `replaceImmutables` function. This was inspired by
smock's `computeStorageSlots`.

Longer term, this code will be rewritten in go and be able to
operate on either a LevelDB database (upgrade an existing system)
or a `genesis.json` (good for starting a new network). This is
a requirement because the state surgery is large enough such that
it must bind directly to LevelDB and be in a language that is
relatively fast.

core-utils,contracts-bedrock,ci: OpNodeProvider + check

makefile: `clean-node-modules`

integration-tests: modularize

Bedrock goerli 96f44f79

contracts-bedrock: modularize build

Move away from using a nested api on the messenger
and instead use an imported function

Modularize the build of `contracts-bedrock` so that
more packages can be dev deps. Make it so that the differential
testing build is different than the typescript build.

This is part of the larger sdk integration work, split out
into its own smaller PR.

Implements a simple `OpNodeProvider` that can be used
to query the op-node. It is used as part of a ci check
against the devnet. It should add some more health related
things, now it just prints of rpc responses. This will
help to debug things.

contracts-bedrock: fix typechain export

This was being incorrectly set in the rollup json relative to the
HD path supplied to the batcher was. This resulted in L2 reorgs
on the sequencer & the inability to send L2 transactions.
Co-authored-by: Mark Tyneway <mark.tyneway@gmail.com>

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

contracts-bedrock: update hardhat-forge plugin

Adds a helper to the makefile for deleting all of the js
deps. This is useful for when checking out a new branch
and ensuring that the deps are up to date. I find
myself doing this often manually, so adding a make command
makes sense.

Updates the hh forge plugin to the following:

```
"@foundry-rs/hardhat-forge": "^0.1.16"
```

Includes bugfixes for when multiple imports
of contracts with the same name happens.

contracts-bedrock: update hardhat forge dep

The `package.json` defines the files that are included
in the `npm` package, the previous glob did not match
all of the typechain artifacts.

ci: remove publishing of deprecated images

op-bindings: speed up build

* contracts-bedrock: fix build

Standardize on the upgradable initializable since the contracts
are technically upgradable it is more clear. There are no real
implementation differences between the upgradable and standard
initializable implementations. `OwnableUpgradable` is `initializable`
imported from the upgradable package, and the `L2OutputOracle`
inherits from `OwnableUpgradable`. This means that the only
way to standardize on a single implementation of `Initializable`
is to use the upgradable version.

This also bumps the version of the openzeppelin contracts
dependency because they refactored the initializable implementation
and made it easier to understand.

https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable/releases/tag/v4.7.0
https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3450

* op-bindings: regenerate

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

Use only 1 initializable instead of two different initializable
imports. Using contracts with the same name will break hardhat.

The two different initializable imports were:

```solidity
import { Initializable } from "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
```

```solidity
import { Initializable } from "@openzeppelin/contracts/proxy/utils/Initializable.sol";
```

This standardizes on not using `contracts-upgradeable`.