Resilience against imprecise exceptions

Right now, the node intentionally crashes when encountering an (impure) exception in certain components (such as in the Chain selection logic), in opposition to exceptions in the threads managing outbound connections.

Now consider a block that causes the Ledger to throw an imprecise exception upon validation. When we receive such a block and add it to the ChainDB, we will save it to disk, even before starting to validate its body. Assuming the exception bubbled up normally and caused the process to exit, the block has been persisted to the VolatileDB. When starting up, the ChainDB will perform initial chain selection for all blocks in the VolatileDB; if this ends up trying to validate the "poisoned" block again, we would enter a crash-reboot loop.

There are multiple potential mitigations:

- Only save the blocks after we have validated them. As blocks can be submitted out-of-order, and we might want to pipeline the block, we would have to implement an in-memory cache for not-yet-validated blocks, such that they vanish on restart and will not be considered in initial chain selection.

Concerns: non-minimal; needs careful thought on e.g. the upper bound for this cache

- Handle imprecise exceptions when validating blocks in the ChainDB; potentially only for the initial chain selection on startup.

Concerns: What kind of exceptions to handle? (i.e. no async exceptions)

In our call yesterday, we estimated the second option to have a higher power-to-weight ratio.