rabbit_mnesia: Make some functions backward-compatible

... with older RabbitMQ versions which don't know about Khepri.

[Why]
When an older node wants to join a cluster, it calls `node_info/0` and
`cluster_status_from_mnesia/0` directly using RPC calls. If it does that
against a node already using Khepri, t will get an error telling it that
Mnesia is not running. The error is reported to the end user, making it
difficult to understand the problem: both nodes are simply incompatible.

It's better to leave the final decision to the Feature flags subsystem,
but for that, `rabbit_mnesia` on the newer Khepri-based node still needs
to return something the older version can accept.

[How]
`cluster_status_from_mnesia/0` and `node_info/0` are modified to verify
if Khepri is enabled and if it is, return a value based on Khepri's
status as if it was from Mnesia.

This will let the remote older node to continue all its checks and
eventually refuse to join because the Feature flags subsystem will
indicate they are incompatible.

Author: dumbbell

deps/rabbit/src/rabbit_mnesia.erl

@@ -407,7 +407,24 @@ cluster_nodes(WhichNodes) -> cluster_status(WhichNodes).
 cluster_status_from_mnesia() ->
     case is_running() of
         false ->
-            {error, mnesia_not_running};
+            case rabbit_khepri:get_feature_state() of
+                enabled ->
+                    %% To keep this API compatible with older remote nodes who
+                    %% don't know about Khepri, we take the cluster status
+                    %% from `rabbit_khepri' and reformat the return value to
+                    %% ressemble the node from this module.
+                    %%
+                    %% Both nodes won't be compatible, but let's leave that
+                    %% decision to the Feature flags subsystem.
+                    case rabbit_khepri:cluster_status_from_khepri() of
+                        {ok, {All, Running}} ->
+                            {ok, {All, All, Running}};
+                        {error, _} = Error ->
+                            Error
+                    end;
+                _ ->
+                    {error, mnesia_not_running}
+            end;
         true ->
             %% If the tables are not present, it means that
             %% `init_db/3' hasn't been run yet. In other words, either
@@ -475,8 +492,23 @@ members() ->
     end.
 
 node_info() ->
+    %% Once Khepri is enabled, the Mnesia protocol is irrelevant obviously.
+    %%
+    %% That said, older remote nodes who don't known about Khepri will request
+    %% this information anyway as part of calling `node_info/0'. Here, we
+    %% simply return `unsupported' as the Mnesia protocol. Older versions of
+    %% RabbitMQ will skip the protocol negotiation and use other ways.
+    %%
+    %% The goal is mostly to let older nodes which check Mnesia before feature
+    %% flags to reach the feature flags check. This one will correctly
+    %% indicate that they are incompatible. That's why we return `unsupported'
+    %% here, even if we could return the actual Mnesia protocol.
+    MnesiaProtocol = case rabbit_khepri:get_feature_state() of
+                         enabled -> unsupported;
+                         _       -> mnesia:system_info(protocol_version)
+                     end,
     {rabbit_misc:otp_release(), rabbit_misc:version(),
-     mnesia:system_info(protocol_version),
+     MnesiaProtocol,
      cluster_status_from_mnesia()}.
 
 -spec node_type() -> rabbit_db_cluster:node_type().