BITOP bug when called against non existing keys fixed.

In the issue #529 an user reported a bug that can be triggered with the
following code:

flushdb
set a
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
bitop or x a b

The bug was introduced with the speed optimization in commit 8bbc0768
that specializes every BITOP operation loop up to the minimum length of
the input strings.

However the computation of the minimum length contained an error when a
non existing key was present in the input, after a key that was non zero
length.

This commit fixes the bug and adds a regression test for it.

src/bitops.c

@@ -197,6 +197,7 @@ void bitopCommand(redisClient *c) {
             objects[j] = NULL;
             src[j] = NULL;
             len[j] = 0;
+            minlen = 0;
             continue;
         }
         /* Return an error if one of the keys is not a string. */

tests/unit/bitops.tcl

@@ -160,4 +160,10 @@ start_server {tags {"bitops"}} {
         catch {r bitop xor dest a b c d} e
         set e
     } {*ERR*}
+
+    test {BITOP with empty string after non empty string (issue #529)} {
+        r flushdb
+        r set a "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
+        r bitop or x a b
+    } {32}
 }