Mostly LGTM.

But I still feel uncomfortable that when I use eval_ro with shebang I have to add no-writes flags, I think eval_ro with shebang should run with no-writes and allow-oom automatically, just like what function evalGetCommandFlags does:

int evalGetCommandFlags(client *c, uint64_t *flags) {
    char funcname[43];
    int evalsha = c->cmd->proc == evalShaCommand || c->cmd->proc == evalShaRoCommand;
    int ro_cmd = c->cmd->proc == evalRoCommand || c->cmd->proc == evalShaRoCommand;
    ...
    if (ro_cmd)
        script_flags |= SCRIPT_FLAG_NO_WRITES;
    *flags = scriptFlagsToCmdFlags(script_flags);
    return C_OK;
}

BTW, now the may-replicate commands are considered write commands in scripts, so we don't need scriptVerifyMayReplicate anymore.

static int scriptVerifyMayReplicate(scriptRunCtx *run_ctx, char **err) {
    if (run_ctx->c->cmd->flags & CMD_MAY_REPLICATE &&
        server.client_pause_type == CLIENT_PAUSE_WRITE) {
        *err = sdsnew("May-replicate commands are not allowed when client pause write.");
        return C_ERR;
    }
    return C_OK;
}

But I still feel uncomfortable that when I use eval_ro with shebang I have to add no-writes flags, I think eval_ro with shebang should run with no-writes and allow-oom automatically, just like what function evalGetCommandFlags does:

Think of functions (not eval), the developer declares if the function is read only, or is allowed to ignore OOM state, the user that calls it doesn't necessarily knows what it does (similar to a module command).

I remind us that the reason we added EVAL_RO was for the purpose of client side routing.
one of the main purposes of this PR (second paragraph at the top comment) was for EVAL to be just as good as EVAL_RO (for client pause) for scripts that declared proper flags.

    if (ro_cmd)
        script_flags |= SCRIPT_FLAG_NO_WRITES;

i don't know why i added that. it doesn't seem that it's needed for any of my tests, it'll just allow the code to pass processCommand and fail in scriptPrepareForRun

BTW, now the may-replicate commands are considered write commands in scripts, so we don't need scriptVerifyMayReplicate anymore.

right, i'll delete it.

@MeirShpilraien i did list the breaking changes at the top (i invite you to review it and comment if it's unclear), and i'll mention them in the release notes.
i also prepared a doc PR (listed in the top comment), please review that one as well.

all, while working on this, and testing OOM errors from EVAL that's called by RM_Call, i found another bug.
the code in processCommand that sets server.script_oom was trying to avoid changing it while a script a busy script yields, but it meant that EVAL that's called by RM_Call can get executed with an outdated flag, i'll update the top comment to mention that bug too.

@soloestoy please have a look at 3bc867f

sorry for the mess. moved the script_oom bugfix to #10786 where fix other related issues and add a new RM_Call flag that needs it.

It's complicated to separate these various fixes since they're all triggered by extra coverage tests, so the tests are all conflicting between these PRs, but i wanna try to have the PRs small with clear topic and description

Think of functions (not eval), the developer declares if the function is read only, or is allowed to ignore OOM state, the user that calls it doesn't necessarily knows what it does (similar to a module command).

I know the flags are script's attributes not the command's, but eval and eval_ro have a different with functions, they can call and modify the script's body, that makes eval and eval_ro more complex. It's OK to me, I don't insist on changing it, but I'm afraid some users may misunderstand it.

Another question I wanna discuss, now when write paused, eval_ro and fcall_ro will be blocked if using them to call a script without no-writes flag, do you thinks it's better to return an error instead of block them?

I know the flags are script's attributes not the command's, but eval and eval_ro have a different with functions, they can call and modify the script's body, that makes eval and eval_ro more complex. It's OK to me, I don't insist on changing it, but I'm afraid some users may misunderstand it.

are you also suggesting a different default behavior for EVAL_RO vs EVALSHA_RO?
i.e. that since EVAL_RO has the script embedded in the RO command it'll have default of no-writes and for EVALSHA_RO it'll be similar to FCALL_RO (same defaults as normal FCALL)?

i think we should keep these _RO commands the same as the non-RO commands, and just say that they're for client routing and ACL.

Another question I wanna discuss, now when write paused, eval_ro and fcall_ro will be blocked if using them to call a script without no-writes flag, do you thinks it's better to return an error instead of block them?

in theory, your suggestion would make a better experience (return error right away, rather than block and return error when unblocked). but in practice, it's a programming mistake that will be discovered by the programmer when testing the script (on normal state), long before ever getting to run it in CLIENT PAUSE state, so it doesn't make any difference, and i rather not complicate the redis code for that (whatever simpler is good in my book)

are you also suggesting a different default behavior for EVAL_RO vs EVALSHA_RO?
i.e. that since EVAL_RO has the script embedded in the RO command it'll have default of no-writes and for EVALSHA_RO it'll be similar to FCALL_RO (same defaults as normal FCALL)?

nope, I don't want make it too much complex, just keep it