feat: Track world state db versions and wipe the state upon version change

[PhilWindle]

Implements a very basic mechanism of tracking changes to the world state DB structure and deleting the world state when a change is detected.

[spalladino]

LGTM, I'd change the file contents though to make them readable.

Aside from that, and not for this PR, should we add a "delete if incompatible" flag that defaults to false, so a configuration issue does not lead to the whole db being nuked?

[spalladino]

Should we use a string representation instead, so the file is human-readable?

[PhilWindle]

Yeah, I agree

[PhilWindle]

LGTM, I'd change the file contents though to make them readable.

Aside from that, and not for this PR, should we add a "delete if incompatible" flag that defaults to false, so a configuration issue does not lead to the whole db being nuked?

I'm wondering if actually we shouldn't delete the DB at all. Just log a big ERROR and quit the application. Let the user do the deleting? What do you think @alexghr @spalladino?

[spalladino]

I'm wondering if actually we shouldn't delete the DB at all. Just log a big ERROR and quit the application. Let the user do the deleting?

Honestly, today I'd go with whatever is easier for the spartan deployments we're running. Given we're still working with very ephemeral networks, maybe we do want to delete it for convenience.

[alexghr]

I'm wondering if actually we shouldn't delete the DB at all. Just log a big ERROR and quit the application. Let the user do the deleting? What do you think @alexghr @spalladino?

On the one hand, I would prefer this (principle of least surprise), on the other hand, in k8s how convenient is it for people to manually log into their production cluster to delete a volume to restart their node?