changing addReplySds and sdscat to addReplyStatusLength() within luaReplyToRedisReply() (#11556)

profiling EVALSHA\ we see that luaReplyToRedisReply takes 8.73% out of the
56.90% of luaCallFunction CPU cycles.

Using addReplyStatusLength instead of directly composing the protocol to avoid
sdscatprintf and addReplySds ( which imply multiple sdslen calls ).

The new approach drops
luaReplyToRedisReply CPU cycles to 3.77%

(cherry picked from commit 68e87eb088)

src/script_lua.c

@@ -651,7 +651,7 @@ static void luaReplyToRedisReply(client *c, client* script_client, lua_State *lu
         if (t == LUA_TSTRING) {
             sds ok = sdsnew(lua_tostring(lua,-1));
             sdsmapchars(ok,"\r\n","  ",2);
-            addReplySds(c,sdscatprintf(sdsempty(),"+%s\r\n",ok));
+            addReplyStatusLength(c, ok, sdslen(ok));
             sdsfree(ok);
             lua_pop(lua,2);
             return;

src/server.h

@@ -2467,6 +2467,7 @@ void addReplyBulkCString(client *c, const char *s);
 void addReplyBulkCBuffer(client *c, const void *p, size_t len);
 void addReplyBulkLongLong(client *c, long long ll);
 void addReply(client *c, robj *obj);
+void addReplyStatusLength(client *c, const char *s, size_t len);
 void addReplySds(client *c, sds s);
 void addReplyBulkSds(client *c, sds s);
 void setDeferredReplyBulkSds(client *c, void *node, sds s);