WiP: Malfeasance v2: Handlers and Publishers

[fasmat]

Motivation

This PR adds handlers and publishers for malfeasance v2 proofs. This is a pre-requisite for enabling v2 ATXs on mainnet.

Closes #6143

Description

For this the existing malfeasance handler has been simplified again to only handle v1 proofs, with the goal of eventually retiring v1 malfeasance proofs in a future release. For malfeasance v2 new handlers and publishers were added.

Dedicated publishers for v1 and v2 proofs have been added, shifting the responsibility for publishing proofs from the handlers of components (activation, hare etc.) to dedicated services. This also allows to simplify handling proof publication since the components now don't need to keep track any more if they are in sync or not before publishing a proof (the publisher now keeps track of this instead).

The new DB table malfeasance requires foreign key constraints so these have now been enabled using PRAGMA foreign_keys = ON;. The new table will keep track of malicious identities and their proofs. The existing identities table will in future only be used to keep track of which identities belong to which marriage set. The proofs in them will be dropped when the publisher / handler of malfeasance v1 proofs are retired and existing proofs will be migrated to V2.

The general pattern for handling malfeasance v2 proofs is:

1. receive proof via sync or gossip (malfeasance hander)
   • if the sender of the proof is self (because we just published the proof) return without doing anything (proof is already validated and persisted during publish)
2. call domain specific malfeasance handler to validate the proof for the identity marked as malicious by the proof (e.g. atx malfeasance handler)
3. if proof is valid evaluate the provided certificates to be valid (in the general malfeasance handler)
4. store proof for the given identity and update the equivocation set to contain all identities that were not known to be part of the set before

The general pattern for publishing a malfeasance proof is:

1. in some domain malicious behavior is detected and a domain specific proof is created for it (eg. double marry in activation domain)
2. proof is passed to the domain specific publisher, which validates the proof to ensure that if we publish it others will also consider it valid
3. domain specific publisher passes the proof along to the general malfeasance publisher that stores the proof
4. if the node is in sync the general publisher publishes the proof to the network via libp2p (otherwise it is only persisted)

Test Plan

• existing tests were updated
• tests have been added for the new functionalities

TODO

• [x] Explain motivation or link existing issue(s)
• [ ] Test changes and document test plan
• [ ] Update documentation as needed
• [ ] Update changelog as needed