@oranagra @yoav-steinberg
Due to the change in #9003, a long-standing bug was raised under valgrind.
This bug can cause the master-slave sync to take a very long time, causing the pendingquerybuf.tcl test to fail.
This problem does not only occur in master-slave sync, it is triggered when the big arg is greater than 32k.
step:

dd if=/dev/zero of=bigfile bs=1M count=32
./src/redis-cli -x hset a a < bigfile

1. Make room for querybuf in processMultibulkBuffer, now the alloc of querybuf will be more than 32k.
   

   redis/src/networking.c

   Line 2159 in b586d5b

   c->querybuf = sdsMakeRoomForNonGreedy(c->querybuf, readlen);

2. If this happens to trigger the clientsCronResizeQueryBuffer, querybuf will be resized to 0.
3. Finally, in readQueryFromClient, we expand the querybuf non-greedily, from 0 to 32k.
   Old code, make room for querybuf is greedy, so it only needs 11 times to expand to 32M(16k*(2^11)), but now we need 2048(32*1024/16) times to reach it, due to the slow allocation under valgrind tha exposed the problem.

The fix for the excessive shrinking of the query buf to 0, will be handled in #5013 (that other change on it's own can fix failing test too), but the fix in this PR will also fix the failing test.

The fix in this PR will make the reading in readQueryFromClient more aggressive when working on a big arg (so that it is in par with the same code in processMultibulkBuffer (i.e. the two calls to sdsMakeRoomForNonGreedy should both use the bulk size).
In the current code (before this fix) the one in readQueryFromClient always has readlen = PROTO_IOBUF_LEN