Get rid of Consensus

[damip]

Rationale

Since the refactoring, block production, operation management etc... were all removed from Consensus.
Consensus now only manages the block graph, ticks for the block graph, and communication between graph and other modules.
It also uses async for no good reason.

TODO in this PR

• remove massa-consensus-exports
• remove massa-consensus-worker
• split massa-graph into:
  • massa-consensus-worker: to run a separate worker thread with its own clock ticker and that directly talks to other modules (no async)
  • massa-consensus-exports for the consnensus controller trait and various exports (no async)

[gterzian]

I think we should first fix all consensus tests and do other clean-ups first, otherwise it's going to be very hard to resolve the conflicts with this proposed refactoring.

Also, the use of async and the fact that "consensus" doesn't do much besides managing graph, is not a big problem right now, so it could be done for the next testnet?

[damip]

Yes let's keep it for testnet 15. Together with #2895

[sebastien-forestier]

I still don't think "graph" is a good module name, there are graphs in other places, and it does not reflect what's going on inside... so why no going for "consensus" or "blockclique" or "Nakamoto" or "clique" or "bestclique" ?

[damip]

because this module does all the block graph handling (dependency tree resolution AND graph storage AND compatibility graph computation AND clique computations AND nakamoto) but doesn't do all the consensus (the final state/ledger is also part of the consensus but is not handled by this module)

[damip]

Actually after thinking more about it I think you're right @sebastien-forestier , "consensus" sounds better :)

[AurelienFT]

Done in #3162