SoR history gaps when heartbeat call fails

[tarakby]

Problem

The current SoR history contract assumes a heartbeat function is called at every block to record the SoR corresponding to that block. This is currently done by a system transaction included in every block. Recently (Feb 2024), an update to core-contracts has called the heartbeat function to fail (this is because of a circular dependency in core-contracts that is outside the scope of this issue). This resulted in the SoR history not being recorded for a range of blocks (till the core-contracts got back to a working state). The SoR corresponding to a block of height h is now only available after the gap length (about 200 blocks), instead of right away in height h+1. While there is no security impact of this failure as the SoR committed to in a height h is still unpredictable and is only revealed in a future block, the delay in revealing the SoR isn't deal for applications. Moreover, accessing the SoR history on a block index h, returns the the SoR generated by the protocol in block h-200.

Fix

• first option: fix the root cause which is the circular dependency of core-contracts that can break a contract during an update. This is the topic of another issue.
• second option regardless of whether the first option is implemented: update the SoR history contract to be more robust against occasional non calls of the heartbeat function in some blocks. This is the topic of this issue. Updating the contract should also fix the current on-chain state of the SoR array