Tezlink: monitor/heads RPC

What

This MR implements the monitor/heads RPC in Tezlink, allowing real-time monitoring of new block heads.

How

• The RPC is implemented by subscribing to the blueprint stream and reading the corresponding block data from storage.
  • Since blueprint application events are emitted before the database is fully written, we introduce a retry mechanism: the system attempts to read the block up to 4 times with incremental delays. If unsuccessful, a warning event is emitted.
• Imported the monitor_heads service definition from Layer 1 (L1) and integrated it into Tezlink.
• Added Lwt_watcher as a dependency in lib-tezlink for stream handling.
• Registered the monitor_heads RPC in the Tezlink RPC directory.
• Created a helper function to spawn processes that trigger hooks immediately upon logging, which is necessary when the process never terminates to capture the logs.
• Developed a test that produces 4 blocks and verifies that 4 corresponding block heads are correctly received through the monitoring RPC.

Design choices

The implementation of this RPC depends directly on the blueprint-applied event. This event is emitted after the database signals that the data has been written. However, experience indicates that immediately attempting to read this data often fails because the data isn't fully available yet. While adjusting the timing or conditions for emitting this event could potentially solve this issue, such a change risks unintended side effects throughout the protocol, particularly since this RPC currently appears to be the only feature requiring this level of precision. Therefore, we opted for a simpler and safer approach—introducing a short delay and retrying if the read initially fails.

Additionally, during testing, it became apparent that rapidly producing blocks could cause corrupted or inconsistent data reads from storage. To mitigate this, the test implementation was adjusted to ensure a new block is only produced once the RPC confirms reception of the previous one. Interestingly, this aligns closely with the current use of monitor_head, where certain protocol operations are paced according to similar events.

Manual Testing

To manually test the MR, run:

dune exec etherlink/tezt/tests/main.exe -- tezlink monitor_heads alpha latest --verbose