Cleanup usage of SyncManager and Settings across codebase.

[piotrm50]

I changes Settings.LatestCommitment and Settings.LastFinalizedSlot usages that require taking the values from the underlying KVStore, to use SyncManager which stores the value in memory.
Values from Settings are still used during component initialization to avoid potential problems due to order in which components are initialized and in some low-level Storage logic.

[cyberphysic4l]

Would it also be worth considering an in-memory latestCommitment for the notarization manager? storage.Settings() is accessed very frequently there.

Apart from that consideration, it all looks good to me

[jonastheis]

I think this PR is fine for now.

However, we should re-think Settings and the SyncManager altogether imo.
Currently, Settings is a weird mix of the state of an engine and its configuration. This becomes quite clear when looking at its Export method. Where we only export

• latest commitment
• latest finalized slot (is this even good? as it might lead to different snapshots (when comparing directly or just hashes) as it incorporates a subjective measure. maybe it should be the finalized slot at the export slot or something)
• protocol versions
• future protocol parameters
• protocol parameters

All the rest is more of a state.

As for the SyncManager this is more like a state of the engine. In a future PR we should probably move all state related properties to the SyncManager, maybe consider renaming it and implement a reactive wrapper around kvstore.TypedValue for convenience access and subscription to changes.

[jonastheis]

Would it also be worth considering an in-memory latestCommitment for the notarization manager? storage.Settings() is accessed very frequently there.

It is used in a few different places across the code, however to me it looks like it's only executed when the node is not bootstrapped yet or when we're committing (which happens only every 10s).

Looking a bit closer at the settings we can see that the latestCommitment is stored as *kvstore.TypedValue[*model.Commitment] which actually manages an in-memory version abstracted away.