Interop: XSafe Head Maintainer

[axelKingsley]

Mechanics for keeping the X-Heads up to date for all chains.

The basic components are:

SafetyChecker(s)

Each Safety Checker knows how to read the Heads Storage for the appropriate Cross/Local head for the type the checker is concerned about. It is also able to Check a log message against the database, confirming that the executing message is valid, and is inside the associated local-head. Finally, Safety Checkers can create Update Operations which modify the Heads when Applied.

Safety Checkers currently can be created through a constructor that switches on a provided string ["safe", "unsafe", "finalized"].

ChainsDB Entypoint for Updates

The ChainsDB now has a function which can use a Safety Checker to advance the cross-heads of all chains.
It also contains a function which creates a Safe-Safety-Checker and uses it to update the X-Safe heads

Interface Updates

As needed, interfaces were expanded or changed. The new interface functions are:

HeadsStorage

• Current - to return a copy of the current Heads in storage
• Apply - to apply an update to the stored Heads

LogDB

• Contains - to check if a matching message is stored in the DB
• LastCheckpointBehind - to go from any index into the DB, back to checkpoint, so that you can use the Iterator
• NextExecutingMessage - takes an iterator, advances it to the next Executing Message, and returns the message.

Iterator

Iterators are now exported so that LogDB can return them in LastCheckpointBehind

• Index - returns the underlying entryDB.EntryIdx, derived as i.nextEntryIdx - 1

Contains

The Contains function now returns the Index the log is located at. This could have replaced the bool value, but for now I wanted to only extend the structure

Tests

Unit tests now exist which test:

• Updating the x-heads works, does not surpass the local head, and does not advance on error
• Checkers return the expected values and return correctly when calling Check

Not Included

Not yet included is the actual trigger that makes this update happen. This should be as simple as a timer-loop, and could also leverage some self-feeding (if an update occurs on one chain, update other chains)