This is a follow-up on #4623, based on the latest comments.

Is something more from the resetCommand needed? I suspect these could be needed:

discardTransaction(c);
pubsubUnsubscribeAllChannels(c,0);
pubsubUnsubscribeAllPatterns(c,0);

We certainly need discardTransaction(c) maybe other parts of reset too, just need to make sure they don't have any side effect of causing slowness when there's nothing to reset (e.g. Nothing to unsubscribe) .

I was thinking about making the server struct member a stack (list) so that repeated calls to RM_Call enjoy some re-use, but then a single nested call would still create a new client, so maybe we better look into why these allocations are so expensive instead.

Last commits add all the necessary reset steps. They are no-ops in the normal case. I've compared with what resetCommand and freeClient are doing.

I was thinking about making the server struct member a stack (list)

This PR adds the most simple optimization with a single client. I think module-call-module is a corner case already.

If it's actually common enough that it needs to be optimized, we could also use small fixed size array of clients (e.g. 3 or 4 clients), where each RM_Call can loop over them to find one which is free to use (it's free if argv == NULL). No need to allocate the list nodes in that case.

I think this is a great improvement as it is.