rabbit_khepri: Use low-latency favor for read-only transactions

Read-write transactions behave like commands (for example 'put' or
'delete') but read-only transactions behave like queries (for example
'get' or 'exists'). When a transaction is passed as read-only we can
re-use the same default options we use for most Khepri queries and
favor low-latency queries. This reads the values from the local node
rather than the leader (or a consistent query), making the query faster
and preventing timeouts when attempting the query when the cluster is
in minority.

The child commit will update some read-only transaction callsites that
take advantage of this low-latency favor.

Author: the-mikedavis

deps/rabbit/src/rabbit_khepri.erl

@@ -974,7 +974,16 @@ transaction(Fun, ReadWrite) ->
     transaction(Fun, ReadWrite, #{}).
 
 transaction(Fun, ReadWrite, Options0) ->
-    Options = maps:merge(?DEFAULT_COMMAND_OPTIONS, Options0),
+    %% If the transaction is read-only, use the same default options we use
+    %% for most queries.
+    DefaultQueryOptions = case ReadWrite of
+                              ro ->
+                                  #{favor => low_latency};
+                              _ ->
+                                  #{}
+                          end,
+    Options1 = maps:merge(DefaultQueryOptions, Options0),
+    Options = maps:merge(?DEFAULT_COMMAND_OPTIONS, Options1),
     case khepri:transaction(?STORE_ID, Fun, ReadWrite, Options) of
         ok -> ok;
         {ok, Result} -> Result;