Resolving serai_consensus into a proper sc_tendermint

[kayabaNerve]

As of now, there's Tendermint Machine, an implementation of the academic protocol left isolated for not only universal use, yet rigorous testing without complications.

This is being bound into Substrate via serai_consensus, which also takes the liberty of defining the entire block production pipeline with specific types. This issue is meant to discussion resolution of various non-Substrate patterns present in serai_consensus, where if all were resolved, this crate could even be offered under Substrate itself.

The benefit to such would be the wider eyes we'd gain our work, potentially including support/review from other parties.

Usage of a custom Substrate fork

This is tracked in #135.

Unification of BlockImport, JustificationImport, and Verifier

This was done as the straightest way forward since Tendermint details block production and finalization. There remains benefit to more modularity as with it comes flexibility. This may already happen before the tendermint branch is merged.

Lack of use of the traditional block pipeline

Instead of receiving blocks with seals, we use the Tendermint process to receive blocks and the temporal Tendermint proposal message (along with the current clock) acts as the seal. While we could use the existing process, it'd require moving the propose message handling out of the Tendermint machine, and break that desired bound. While it may be fine to maintain this custom pipeline, doing so breaks interoperability within Substrate, meaning we can likely never create a fully-Substrate-esque crate.

Custom handling of inherent transactions

We bypass inherent transaction checks when a block is finalized. A Parity developer explicitly told me inherent transactions were not intended for the flow used in Serai, and this flow which enables their usage as such may not be deemed Substrate-esque. It could be argued as a valid optimization though and harmless to Parity's intention for inherent transactions.

Strict handling of the import pipeline

We ban post-digests and auxiliary data. While Substrate itself will error if auxiliary data remains at the end, we don't allow it when the Tendermint importer is called. This was intended to protect against unforeseen cases/malleability and ensure security, yet may break interoperability (though I'm unsure what such interoperability would be).

Children on-chain with a lower priority than their parents

In order to fully validate blocks, we must import them, yet imported blocks (under PoW/BABE/Aura) are intended to built upon. Under Tendermint, only the finalized block should be. The workaround was to import with a lower preference than the chain tip, then trigger moving to them by finalizing when the time comes. This can't be resolved with the SelectChain API, mainly used by nodes (I don't see it used within Substrate), yet highlights incompatibilities with the Substrate design and Tendermint.

Forced usage of Ristretto and Ristretto alone.

This was to absolve myself of some of the pain of the amount of generics in use. With the recent move to a monolith of associated types which are tightly bound, it should be bearable now.

[kayabaNerve]

serai_consensus no longer exists.

AFAIK, the whole post-digest discussion would relate to a system like Beefy.

The only further thing I care to do at this time, without feedback/requests, would be modularize out Ristretto.