Swap mnesia and feature flags syncs

[dumbbell]

It depends on #6810.

[dumbbell]

I'm writing down the status to remember where I was after the holidays season.

This branch, which is based onto #6810 (making feature_flags_v2 required) currently tries to make all feature flags required (except those introduced in main for RabbitMQ 3.12.0). This permitted to discover several small bugs in the feature flags subsystem.

In CI, there is one last testsuite failing, peer_discovery_classic_config_SUITE. My current understanding is that peer discovery on node 2 (running v3.11.x) may see the two other nodes or not, depending on how fast they all boot.

If it thinks it's alone at that point, it enabled the feature flags listed in $RABBITMQ_FEATURE_FLAGS and everything is fine. However if it sees the other nodes, it will try to sync the feature flags state with them. This will fail because required feature flags can't be enabled at that point on node 2 (it's too late and other nodes will refuse to set the states to state_changing to let node 2 runs the migration functions.

One possibility is to take into account the NodeIsVirgin argument to rabbit_feature_flags:sync_feature_flags_with_cluster/2 even if the given list of nodes is non-empty. We could query the list of required feature flags from remote nodes and mark them as enabled right away. The node being virgin, there is nothing to migrate anyway. We would have to do that for both v1 (v3.11.x and v3.10.x, perhaps v3.9.x) and v2 (main and v3.11.x).

[dumbbell]

I'm no longer sure we need to change anything in fact. The feature flags subsystem is already initialized before Mnesia; it's the cluster synchronization which happens during Mnesia init and it has to stay like that because we need to know cluster members. The same will be try with Khepri.

We will still need to add an abstraction layer on top of Mnesia for the following needs:

• the db initialization
• to determine if a node if virgin
• to get the list of cluster members

This should be provided by rabbit_db.