khepri_cluster: Use key metrics to determine if a Ra server is running

[Why]
The previous use of `ra:ping/2` was too expensive.

As
`khepri_cluster:is_store_running/1` is now used by
`mnesia_to_khepri:is_migration_finished/2` and
`mnesia_to_khepri:hande_fallback/5` since khepri_mnesia_migration 0.6.0,
we saw a regression in performance in RabbitMQ because of this.

khepri_mnesia_migration was using a very basic and incomplete version of
`is_store_running()` before. That's why the issue was not spotted
earlier.

[How]
The new code uses `ra:key_metrics/2` which simply checks if the process
us running and query a few local counters. This is way faster because it
does not send messages to the Ra server.

src/khepri_cluster.erl

@@ -1560,11 +1560,9 @@ get_store_ids() ->
 is_store_running(StoreId) ->
     ThisNode = node(),
     RaServer = khepri_cluster:node_to_member(StoreId, ThisNode),
-    Runs = case ra:ping(RaServer, khepri_app:get_default_timeout()) of
-               {pong, _}  -> true;
-               {error, _} -> false;
-               timeout    -> false
-           end,
+    Timeout = khepri_app:get_default_timeout(),
+    KeyMetrics = ra:key_metrics(RaServer, Timeout),
+    Runs = maps:get(state, KeyMetrics) =/= noproc,
 
     %% We know the real state of the Ra server. In the case the Ra server
     %% stopped behind the back of Khepri, we update the cached list of running
@@ -1573,6 +1571,10 @@ is_store_running(StoreId) ->
     case maps:is_key(StoreId, StoreIds) of
         true when Runs ->
             ok;
+        false when Runs ->
+            %% This function was called between the start of the Ra server and
+            %% the record of its configuration. This is a race, but that's ok.
+            ok;
         false when not Runs ->
             ok;
         true when not Runs ->