RATIS-2505. Improve RATIS-2387 with direct synchronous append when compose disabled

[ss77892]

What changes were proposed in this pull request?

When appendEntriesComposeEnabled is disabled (set to false), the code now bypasses the appendLog() method entirely and invokes the append operation directly on the current thread. This change eliminates the unnecessary async hop that remained in RATIS-2387. Instead of creating a completed future and then using thenComposeAsync() to schedule the append on the executor, the append now happens immediately on the calling thread.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/RATIS-2505

How was this patch tested?

Ozone cluster deployment with high volume write load.

[ss77892]

@szetszwo, you might find it interesting.

[szetszwo]

The change looks good. However, could you make it a one-line change?

+++ b/ratis-server/src/main/java/org/apache/ratis/server/impl/RaftServerImpl.java
@@ -1682,7 +1682,7 @@ class RaftServerImpl implements RaftServer.Division,
     future.join();
     final CompletableFuture<Void> appendFuture = entries.isEmpty()? CompletableFuture.completedFuture(null)
         : appendLogTermIndices != null ? appendLogTermIndices.append(entries, this::appendLog)
-        : appendLog(entries);
+        : JavaUtils.allOf(state.getLog().append(entries));

     proto.getCommitInfosList().forEach(commitInfoCache::update);

[yandrey321]

can we cover these changes with unit tests?

[szetszwo]

This revert the code to pre- RATIS-2235. So, new unit tests probably are not needed.

[ss77892]

@szetszwo sure. I just thought that if/else is easier to understand.

[szetszwo]

+1 the change looks good.

[szetszwo]

... I just thought that if/else is easier to understand.

Different people have a different taste. If it is new code, it is fine either way. But for the existing code, let's just minimize the change.