Trie: Better Structured & Expanded Checkpointing Tests #3701
Description
This is a follow-up on #3645, post by @TimDaub.
So the mentioned issue is about trie failures in the context of checkpointing usage. I guess the only realistic way that we can catch this respectively generally make this part of Trie more robust is by expanding on the checkpointing tests from here.
These are not as structured and do not cover as much the complete range of combinations as the lot more structured StateManager tests.
So I guess the best way is to somewhat more align and roughly (trie adopted with key/values for sure) the labelling mechanism from the SM tests (e.g. A1.1 -> CP -> A1.2 -> Revert -> Flush() (-> A1.1)) and then inject/integrate the existing trie checkpointing tests (or: move over) and then see which cases are left and fully add these as new tests.
(this would be generally good to have this, since if we identify a new missing combination in the future in one of the libraries, it get's a lot easier to just directly add to the other)
From my intuition I would guess chances are somewhat high that we discover 1-2 bugs by this (> 50%, we'll see).