refactor: improved initialization of members of LLMQContext and related changes

[knst]

LLMQContext uses RAII to initialize all members. Ensured that all members always initialized correctly in proper order if LLMQContext exists.

BlockAssembler, CChainState use too many agruments and they are making wrong assumption that members of LLMQContext can be constructed and used independently, but that's not true. Instead, let's pass LLMQContext whenever possible.

Issue being fixed or feature implemented

https://github.com/dashpay/dash-issues/issues/52

How Has This Been Tested?

Run unit/functional test and introduce no breaking changes.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone

[github-actions]

This pull request has conflicts, please rebase.

[kwvg]

I attempted to get around the mempool problem by passing them by reference, not sure if this is the best way to do it. kwvg@6396c89 and kwvg@f201072

[knst]

Mempool refactorings moved here: #5169
@kittywhiskers thanks for a comment, I used similar approach.

[github-actions]

This pull request has conflicts, please rebase.

[kwvg]

NACK

NodeContext is a container for references that constitute a node, not a self-contained object that initializes its members or cleans up after itself. There is no NodeContext "unit" to initialize, so to speak, only the container, because that's what NodeContext is.

The burden of initialization of its members falls on each entity's initialization logic (that be setup_common.cpp for tests or init.cpp for daemons), which means when passing a NodeContext, we have to be very sure that everything within it is initialized and valid before passing any instance of it. An assurance that as of now, we cannot make.

This PR at least seems to be less interested in NodeContext's members but rather LLMQContext's and LLMQContext, unlike NodeContext mostly sets itself up and cleans up after, the key word being mostly.

Members of LLMQContext (CQuorumBlockProcessor, CQuorumManager, CChainLocksHandler and CInstantSendManager) are very much globals with its corresponding LLMQContext members being an alias to them, meant to migrate code to using NodeContext (and hence, LLMQContext) when possible and document the dependencies of each subsystem.

That is ultimately why we went with having long argument lists, documentation. During the initial deglobalization effort, it was a painstaking process to document all the uses of a global and then passing them by reference as an argument leading to a common initialization point, I had also attempted to use LLMQContext to cleanup the argument list, but found debugging to be painful as it obscured the order of initialization.

Perhaps if LLMQContext is entirely self-contained and we can guarantee that all its members are initialized before passing it, I would be open to it replacing our (admittedly quite long) arguments but as it stands, I feel it'll cause more problems than it'll solve.

[github-actions]

This pull request has conflicts, please rebase.

[knst]

@PastaPastaPasta I removed commit with new circular dependencies. Please, help to get merged this PR.

[UdjinM6]

re-utACK

[github-actions]

This pull request has conflicts, please rebase.

[UdjinM6]

re-utACK

[PastaPastaPasta]

utACK for squash merge