feat(protocol): use num proposals to measure forced inclusion deadline

[dantaik]

The following changes are implemented in this PR:

1. Replaced timestamp-based deadlines with L2 proposal count: The number of L2 proposals (batches) is now used to determine whether the oldest forced inclusion is due. This change addresses issues related to timestamp-based deadlines (see Brecht's comment).

2. Enabled proactive processing of inclusion requests: Proposers/preconfers are now allowed to proactively process the oldest inclusion request even before it is due.

@cyberhorsey Tests are broken and not yet fixed.

[openzeppelin-code]

feat(protocol): use num proposals to measure forced inclusion deadline

Generated at commit: 55c5b0b97187b9dd1cd9ce661e2c52e2a55af6ab

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	3 3 0 10 40 56
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[smartprogrammer93]

I like it 🙏 Apologies for the force push, just pressed rebase button on github 🤦‍♀️

[AnshuJalan]

@dantaik Will ForcedInclusionInbox only be callable from the PreconfRouter or can anyone permissionless-ly call the required function to clear the oldest forced inclusion?

[dantaik]

Good question. I think we have at least two possible approaches:

1. Independent of the Preconfirmation: The ForcedInclusionInbox could include an additional function allowing any address to permissionlessly propose a batch of blocks, provided that it includes a pending forced inclusion request that has exceeded a certain time threshold.

2. Considering Preconfirmation: If the current preconfer stop proposing blocks, the TaikoInbox or ForcedInclusionInbox (I prefer to rename it to TaikoInboxWrapper) could permit any address to propose blocks/batches once a timeout occurs. This ensures not only that forced inclusion requests are processed, but also that normal blocks can also be proposed to keep the chain alive, when preconfer become inactive.

I believe option 2 is the better approach because, with option 1, we would still need a fallback mechanism to handle cases where preconfers stop working. Option 2 directly addresses this issue by ensuring a permissionless mechanism kicks in when necessary.