This PR addresses the issue where, under memory pressure, a follower  
directly rejects append requests instead of first attempting to free  
up memory by evicting the entry cache.  

One potential solution is for the follower, before rejecting append  
requests, to notify other peers on the same node (including leaders  
and followers) to evict their entry caches. This would require a  
global module that coordinates peers. When many followers on the  
same node receive append requests under memory pressure, they would  
notify the module, which would then send messages to a sufficient  
number of peers to trigger entry cache eviction and report the  
results back to the followers. This module could also be triggered  
by a leader on the same node when it's receiving write requests  
under memory pressure. However, this solution is a bit complex and  
has a low ROI.  

A more practical solution is to optimize the conditions for  
triggering entry cache eviction, so it occurs earlier, avoiding  
append rejection.  

Why doesn't the current version trigger cache eviction earlier?  

Currently, entry cache eviction is checked either by the  
`raft_log_gc_tick_interval` (default 3 seconds) or during  
`handle_raft_committed_entries`. The trigger conditions for eviction  
are:  
1. Total memory usage has reached the high water mark.  
2. Entry cache memory usage has reached the  
`evict_cache_on_memory_ratio` (default 0.1, not visible to the  
customer).  

On the other hand, append rejection is triggered when:  
1. Total memory usage has reached the high water mark.  
2. The total memory usage of the entry cache, raft messages, and  
applying entries has reached the `reject_messages_on_memory_ratio`  
(default 0.2).  

The issue is that when the first condition is met, the second  
condition for append rejection may be triggered earlier.  

The solution proposed in this PR is to modify the first condition  
for cache eviction. Instead of waiting for memory usage to fully  
reach the high water mark, eviction will be triggered when memory  
usage is **near** the high water mark.  

This change should not introduce significant performance overhead  
because eviction is only triggered when memory usage is near the  
high water mark, and it helps prevent the more disruptive append  
rejections.  

None