Fix replicationFeedSlaves() to use sdsEncodedObject() macro.
Fixed a possible bug in client->reply_bytes computation.
Fix setDeferredMultiBulkLength() c->reply_bytes handling with EMBSTR

This function missed proper handling of reply_bytes when gluing to the
previous object was used. The issue was introduced with the EMBSTR new
string object encoding.

This fixes issue #1208.
Test: regression test for issue #1208.
getStringObjectSdsUsedMemory() function added.

Now that EMBSTR encoding exists we calculate the amount of memory used
by the SDS part of a Redis String object in two different ways:

1) For raw string object, the size of the allocation is considered.
2) For embstr objects, the length of the string itself is used.

The new function takes care of this logic.
Every function inside sds.c is now commented.
Inline protocol improved to accept quoted strings.
sdsrange() does not need to return a value.

Actaully the string is modified in-place and a reallocation is never
needed, so there is no need to return the new sds string pointer as
return value of the function, that is now just "void".
fixed bug issue of #1213
Ignore sdsrange return value.
fixed initServer failed if no IPV4 or no IPV6
fixed initServer fail while having no IPv6 nor IPv4
Use latest sds.c in the hiredis library under deps.
Remove dead variable bothsds from object.c.

Thanks to @run and @badboy for spotting this.
Triva: clang was not able to provide me a warning about that when
compiling.

This closes #1024 and #1207, committing the change myself as the pull
requests no longer apply cleanly after other changes to the same
function.
Fix replicationFeedSlaves() off-by-one bug.

This fixes issue #1221.
Test: regression test for issue #1221.
Draft #1 of a new expired keys collection algorithm.

The main idea here is that when we are no longer to expire keys at the
rate the are created, we can't block more in the normal expire cycle as
this would result in too big latency spikes.

For this reason the commit introduces a "fast" expire cycle that does
not run for more than 1 millisecond but is called in the beforeSleep()
hook of the event loop, so much more often, and with a frequency bound
to the frequency of executed commnads.

The fast expire cycle is only called when the standard expiration
algorithm runs out of time, that is, consumed more than
REDIS_EXPIRELOOKUPS_TIME_PERC of CPU in a given cycle without being able
to take the number of already expired keys that are yet not collected
to a number smaller than 25% of the number of keys.

You can test this commit with different loads, but a simple way is to
use the following:

Extreme load with pipelining:

redis-benchmark -r 100000000 -n 100000000  \
        -P 32 set ele:rand:000000000000 foo ex 2

Remove the -P32 in order to avoid the pipelining for a more real-world
load.

In another terminal tab you can monitor the Redis behavior with:

redis-cli -i 0.1 -r -1 info keyspace

and

redis-cli --latency-history

Note: this commit will make Redis printing a lot of debug messages, it
is not a good idea to use it in production.
Darft #2 for key collection algo: more improvements.

This commit makes the fast collection cycle time configurable, at
the same time it does not allow to run a new fast collection cycle
for the same amount of time as the max duration of the fast
collection cycle.
Remove dead code and fix comments for new expire code.
Some activeExpireCycle() refactoring.