refactor: decouple db hooks from CFlatDB-based C*Manager objects, migrate to *Store structs

[kwvg]

Motivation

As highlighted in https://github.com/dashpay/dash-issues/issues/52, decoupling of CFlatDB-interacting components from managers of objects like CGovernanceManager and CSporkManager is a key task for achieving deglobalization of Dash-specific components.

The design of CFlatDB as a flat database agent relies on hooking into the object's state its meant to load and store, using its (de)serialization routines and other miscellaneous functions (notably, without defining an interface) to achieve those ends. This approach was taken predominantly for components that want a single-file cache.

Because of the method it uses to hook into the object (templates and the use of temporary objects), it explicitly prevented passing arguments into the object constructor, an explicit requirement for storing references to other components during construction. This, in turn, created an explicit dependency on those same components being available in the global context, which would block the backport of bitcoin#21866, a requirement for future backports meant to achieve parity in assumeutxo support.

The design of these objects made no separation between persistent (i.e. cached) and ephemeral (i.e. generated/fetched during initialization or state transitions) data and the design of CFlatDB attempts to "clean" the database by breaching this separation and attempting to access this ephemeral data.

This might be acceptable if it is contained within the manager itself, like CSporkManager's CheckAndRemove() but is utterly unacceptable when it relies on other managers (that, as a reminder, are only accessible through the global state because of restrictions caused by existing design), like CGovernanceManager's UpdateCachesAndClean().

This pull request aims to separate the CFlatDB-interacting portions of these managers into a struct, with CFlatDB interacting only with this struct, while the manager inherits the struct and manages load/store/update of the database through the CFlatDB instance initialized within its scope, though the instance only has knowledge of what is exposed through the limited parent struct.

Additional information

• As regards to existing behaviour, CFlatDB is written entirely as a header as it relies on templates to specialize itself for the object it hooks into. Attempting to split the logic and function definitions into separate files will require you to explicitly define template specializations, which is tedious.

• m_db is defined as a pointer as you cannot instantiate a forward-declared template (see this Stack Overflow answer for more information), which is done when defined as a member in the object scope.

• The conditional cache flush predicating on RPC not being in the warm-up state has been replaced with unconditional flushing of the database on object destruction (@UdjinM6, is this acceptable?)

TODOs

This is a list of things that aren't within the scope of this pull request but should be addressed in subsequent pull requests

• Definition of an interface that CFlatDB stores are expected to implement
• Lock annotations for all potential uses of members protected by the cs mutex in each manager object and store
• Additional comments documenting what each function and member does
• Deglobalization of affected managers

[github-actions]

This pull request has conflicts, please rebase.

[github-actions]

This pull request has conflicts, please rebase.

[PastaPastaPasta]

Concept ACK, however let's keep stuff as classes, IMO structs should only be used for very simple data structures, normally with no member functions and minimal data structures

[knst]

check my comments, especially about using mmetaman in net.cpp and net_processing.cpp

[knst]

LGTM

[UdjinM6]

utACK

[PastaPastaPasta]

utACK for squash merge