feat: Data Availability Oracle

[LHerskind]

As proposed in the yellow-paper, we should have a separate contract that handles data availability concerns. The state transitioner then can query this contract to figure out if the data is made available.

It allows us to be more modular with respect to the data layer, and makes it easier for us to switch to blobs or celestia if desired down the line.

Nevertheless, we can do it in multiple iterations to limit the changes to the node at once.
Namely we can at first create the oracle, but still follow the same publication flow, where the block is pushed to the state transitioner and it can then forward it to the data availability oracle.

Afterwards the publication of data and proof can be separated as planned. Note that altering this will also require changing how l2 block content is fetched.

Builders that are optimizing their time to build blocks (such as searcher) could preemptively apply the block changes before it have been proven on.

---

If we replace the available map in the Availability oracle from mapping(commitment: Fr => available: bool) with mapping(commitment: Fr => tx_hash: bytes32) we should be able to more easily get a hold of the data for syncing.

---

Tasks

Preview Give feedback

1. feat: modularize decoder #3890
   +0
   
2. Publish data separately before the transaction with the header (node changes as well) #3944
   +0
   
3. Fetch headers and blocks separately #4167
   0 of 2
   +0
   

[LHerskind]

Closed as its subtasks have been finished.