Fix crash on RM_Call with script mode. (#10886)

The PR fixes 2 issues:

### RM_Call crash on script mode

`RM_Call` can potentially be called from a background thread where `server.current_client`
are not set. In such case we get a crash on `NULL` dereference.
The fix is to check first if `server.current_client` is `NULL`, if it does we should
verify disc errors and readonly replica as we do to any normal clients (no masters nor AOF).

### RM_Call block OOM commands when not needed

Again `RM_Call` can be executed on a background thread using a `ThreadSafeCtx`.
In such case `server.pre_command_oom_state` can be irrelevant and should not be
considered when check OOM state. This cause OOM commands to be blocked when
not necessarily needed.

In such case, check the actual used memory (and not the cached value). Notice that in
order to know if the cached value can be used, we check that the ctx that was used on
the `RM_Call` is a ThreadSafeCtx. Module writer can potentially abuse the API and use
ThreadSafeCtx on the main thread. We consider this as a API miss used.

tests/unit/moduleapi/blockedclient.tcl

@@ -76,6 +76,19 @@ start_server {tags {"modules"}} {
         r do_bg_rm_call hgetall hash
     } {foo bar}
 
+    test {RM_Call from blocked client with script mode} {
+        r do_bg_rm_call_format S hset k foo bar
+    } {1}
+
+    test {RM_Call from blocked client with oom mode} {
+        r config set maxmemory 1
+        # will set server.pre_command_oom_state to 1
+        assert_error {OOM command not allowed*} {r hset hash foo bar}
+        r config set maxmemory 0
+        # now its should be OK to call OOM commands
+        r do_bg_rm_call_format M hset k1 foo bar
+    } {1} {needs:config-maxmemory}
+
     test {RESP version carries through to blocked client} {
         for {set client_proto 2} {$client_proto <= 3} {incr client_proto} {
             r hello $client_proto