Describe the bug

The log error:

CRITICAL failed to run block production engine: cannot handle epoch: cannot initiate and get epoch handler: failed to initiate epoch: cannot get epoch data and start slot: getting epoch data for epoch 19: failed to get epoch data from memory: epoch not found in memory map: 19	pkg=babe

Motivation

• The critical error happens if a new epoch starts and but its data still in memory due to no block finalization (not a problem since block finalization can take sometime to happen)
• If the node is shutdown the next time it restarts it will face the problem: epoch not found in memory map

Explanation about the problem

• The problem happens due to the fact that Gossamer holds valuable information in memory until a finalization happens.
• Currently that happens since is easy to hold and acesses information that needs to be fork-aware (which means, different informations needs to be stored/read for different forks of the chain), for that we use in-memory maps

Suggested approach

• Use the disk to hold such informations as well as keep them in the memory for fast lookup. Once the node starts (fresh or not) read the infos from the disk and place them into memory again, enabling the BABE to start in the correct epoch.
• You can use the current disk database to hold these informations in the following format: key as the following string ${epoch_number}:${fork_hash} and holds the value as the SCALE encoded types.NextEpochData or types.NextConfigDataV1. Look at dot/state/epoch.go the type nextEpochMap which is the one that must be in sync with the disk
• Free the database once a finalization happens, since you're keeping informations about forks, once they got pruned you must remove them (you don't need to keep informations about the finalized one since it will be stored again but in another key/value format)

Acceptance criteria

• Make sure that Gossamer can provide the correct epoch data (simulate using forks) after a shutdown before finalization happens