fatality based errors

[drahnr]

Ref #4440

Note to reviewers:

• focus on the match of #[fatal] and #[fatal(forward)] and the missing annotations with the previous enums NonFatal and Fatal.
• look at the API or quirks that are required, misnomers in the trait Nested or trait Split, these are easy to fix
• ergonomics of the fatality::fatality proc-macro

[ordian]

I like the direction where it's headed. It's be good to see it applied to one subsystem to justify the design.

[eskimor]

Noice!

[ordian]

Looks reasonable overall. We should do a burn-in on Versi to make sure it doesn't introduce early exits or too verbose logging.

One think I prefer about our previous version is that the Fatal, NonFatal was explicit in the naming and here we have to jump to definition to know which one is fatal. But maybe it's not a big deal.

[drahnr]

Technically we can also use the generated variants JfyiError and FatalError, but I wanted to defer the implicitly named types to as little usage as possible. I have an issue (gh doesn't load for me right now) to allow specifying those explicitly.

Could you outline an instance where you think the JfyiError or FatalError should be used rather than Error?

The logging verbosity should be identical to before. If there'd be a change that should be considered a bug.

[drahnr]

Deployed to versi group e for burnin and a

[drahnr]

Logs look good to me for the no disputes case (requires VPN) https://grafana.parity-mgmt.parity.io/explore?orgId=1&left=%5B%221645723532509%22,%221645723543309%22,%22loki.parity-testnet%22,%7B%22refId%22:%22A%22,%22expr%22:%22%7B%20node%20%3D~%20%5C%22versi-validator-a-.*%5C%22%20%7D%22%7D%5D

[drahnr]

Did a last review pass to check the correct split between Jfyi* and Fatal* and it looks all good. Did a few small simplifications, I'll merge this then.

[drahnr]

bot merge

[paritytech-processbot]

Waiting for commit status.