fix: fullnode sync restart

[purusang]

• l2 block finalization is done only if the l2 block actually exists.
• check point finalization is triggered only once in events L1Block or NewTipBlock.

Description

Reason of failing to restart

When fullnode is in initial syncing state, l1 reader/processor reads/processes blocks way faster than l2 block reader/processor. As a result l2blocks that did not exist in l2 db were marked as finalized.

After restart, fullnode tries to perform state transitions from the point where l2 block was last finalized. If l2 block does not exist it crashes.

Solution

In this pr I have changed the behavior of how we actually mark the finalize block. Previously, we were updating finalized block based on checkpoints processed by reading l1 blocks only.
After this pr, we do as previously only if the l2 block actually exist in the l2 db. And for each new l2 block tip we look for any corresponding checkpoint and finalize it if the l2blockid in checkpoint matches.

No effect on Sequencer

Sequencer does not get in this situation so it's work should not be affected.

No effect on fully synced nodes

If fullnode is in sync with realtime chain state then no way it receives any l1 block which will have future l2 checkpoint.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor
• New or updated tests
• Dependency Update

Notes to Reviewers

I want to add it's test case in a separate pr as creating this rare condition is quite tricky in test cases. Any suggestions on test cases for this condition will be highly appreciated.
I have tested these changes against our devnet releases/0.1.0 and the fix must be applied asap to releases.

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

STR-647

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 57 lines in your changes missing coverage. Please review.

Project coverage is 56.12%. Comparing base (7425015) to head (c58fac0).
Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
...rates/consensus-logic/src/csm/client_transition.rs	0.00%	57 Missing ⚠️

@@            Coverage Diff             @@
##             main     #525      +/-   ##
==========================================
- Coverage   58.55%   56.12%   -2.44%     
==========================================
  Files         277      298      +21     
  Lines       29341    30517    +1176     
==========================================
- Hits        17182    17127      -55     
- Misses      12159    13390    +1231     

Files with missing lines	Coverage Δ
...rates/consensus-logic/src/csm/client_transition.rs	58.39% <0.00%> (-6.01%)	⬇️

... and 34 files with indirect coverage changes

[storopoli]

Some nits on docstrings.
The logic looks fine, but I am not a codeowner in this part of the codebase.

[delbonis]

We'll be coming back around to working on some of this later.

[storopoli]

Amazing docstrings.
Just some suggestions.
I still think "slice" is less intuitive than "array". But feel free to disagree and go with "slice".

[storopoli]

ACK c58fac0