Stabilize tests for IO threading (#14138)

- tests/unit/maxmemory.tcl
If multithreaded, we need to let IO threads have chance to reply output
buffer, to avoid next commands causing eviction. After eviction is
performed,
the next command becomes ready immediately in IO threads, and now we
enqueue
the client to be processed in main thread’s beforeSleep without
notification.
However, invalidation messages generated by eviction may not have been
fully
delivered by that time. As a result, executing the command in
beforeSleep of
the event loop (running eviction) can cause additional keys to be
evicted.
```
Expected '73' to be between to '200' and '300' (context: type source line 473 file 
redis/tests/unit/maxmemory.tcl cmd {assert_range [r dbsize] 200 300} proc ::test)
```
the reason why CI doesn't find this issue is that we skill this test
`tsan:skip` as below
`start_server {tags {"maxmemory external:skip tsan:skip"}} `,so remove
this tag.

- tests/integration/aof.tcl
Because IO and the main thread are working in better parallelism without
notification,
the main thread may haven't write AOF buffer into file, but the IO
thread just writes
the reply, so the clients receive the reply before AOF file is changed.
We should use `appendfsync always` policy to make the command is written
into
AOF file when receiving reply.
```
Expected '0' to be equal to '54' (context: type source line 249 file
redis/tests/integration/aof.tcl cmd {assert_equal $before $after} proc ::test)
```

#13969 makes these scenarios easy to appear.

tests/integration/aof.tcl

@@ -239,7 +239,7 @@ tags {"aof external:skip"} {
         }
     }
 
-    start_server {overrides {appendonly {yes}}} {
+    start_server {overrides {appendonly {yes} appendfsync always}} {
         test {GETEX should not append to AOF} {
             set aof [get_last_incr_aof_path r]
             r set foo bar

tests/unit/maxmemory.tcl

@@ -421,13 +421,19 @@ start_server {tags {"maxmemory external:skip"}} {
     } {4098}
 }
 
-start_server {tags {"maxmemory external:skip tsan:skip"}} {
+start_server {tags {"maxmemory external:skip"}} {
     test {client tracking don't cause eviction feedback loop} {
         r config set latency-tracking no
         r config set maxmemory 0
         r config set maxmemory-policy allkeys-lru
         r config set maxmemory-eviction-tenacity 100
 
+        # check if enabling multithreaded IO
+        set multithreaded 0
+        if {[r config get io-threads] > 1} {
+            set multithreaded 1
+        }
+
         # 10 clients listening on tracking messages
         set clients {}
         for {set j 0} {$j < 10} {incr j} {
@@ -465,6 +471,15 @@ start_server {tags {"maxmemory external:skip tsan:skip"}} {
         set limit [expr {$used - 40000}]
         r config set maxmemory $limit
 
+        # If multithreaded, we need to let IO threads have chance to reply output
+        # buffer, to avoid next commands causing eviction. After eviction is performed,
+        # the next command becomes ready immediately in IO threads, and now we enqueue
+        # the client to be processed in main thread’s beforeSleep without notification.
+        # However, invalidation messages generated by eviction may not have been fully
+        # delivered by that time. As a result, executing the command in beforeSleep of
+        # the event loop (running eviction) can cause additional keys to be evicted.
+        if $multithreaded { after 200 }
+
         # make sure some eviction happened
         set evicted [s evicted_keys]
         if {$::verbose} { puts "evicted: $evicted" }