override histfile from env - fixes #831 and copies #833
Add SENTINEL INFO-CACHE [masters...]

Sentinel queries the INFO from every master and from every replica of
every master.

We can cache the INFO results in Sentinel so Sentinel can be a single
place to quickly get all INFO output for an entire Sentinel monitoring
group.

This commit gives us SENTINEL INFO-CACHE in two forms:
  - SENTINEL INFO-CACHE — returns all masters and all replicas
  - SENTINEL INFO-CACHE master0 master1 ... masterN — vararg specify masters

Results are returned as a multibulk reply with two top-level entries
for each master.  The first entry for each master is the name of the master.
The second entry is a nested multibulk reply with the contents of INFO,
first for the master, then an additional entry for each of the
replicas.
Update sds.c

in the case (all chars of the string s found in 'cset' ),
line[573] will no more do the same thing line[572] did.
this will be more faster especially in the case that the string s is very long and all chars of string s found in 'cset'
sds.c: more tests for sdstrim().
test-sds target in Makefile to run sds.c tests.
Merge pull request #2203 from Brochen/unstable

Update sds.c
Merge branch 'unstable' of github.com:/antirez/redis into unstable
Merge pull request #2148 from mattsta/feature/sentinel/info-cache

Add SENTINEL INFO-CACHE [masters...]
Sentinel: INFO-CACHE reply format command shortened.
Sentinel: removed useless flag var from INFO-CACHE.
Sentinel: INFO-CACHE GCC minior code cleanup.

I guess the initial goal of the initialization was to suppress GCC
warning, but if we have to initialize, we can do it with the base-case
value instead of NULL which is never retained.
Sentinel: INFO-CACHE comments reworked a bit.

Changed in order to make them more review friendly, based on the
experience of reviewing the code myself.
Merge pull request #2133 from chooper/histfile-override

override histfile from env - fixes #831 and copies #833
Better read-only behavior for expired keys in slaves.

Slaves key expire is orchestrated by the master. Sometimes the master
will send the synthesized DEL to expire keys on the slave with a non
trivial delay (when the key is not accessed, only the incremental expiry
algorithm will expire it in background).

During that time, a key is logically expired, but slaves still return
the key if you GET (or whatever) it. This is a bad behavior.

However we can't simply trust the slave view of the key, since we need
the master to be able to send write commands to update the slave data
set, and DELs should only happen when the key is expired in the master
in order to ensure consistency.

However 99.99% of the issues with this behavior is when a client which
is not a master sends a read only command. In this case we are safe and
can consider the key as non existing.

This commit does a few changes in order to make this sane:

1. lookupKeyRead() is modified in order to return NULL if the above
conditions are met.
2. Calls to lookupKeyRead() in commands actually writing to the data set
are repliaced with calls to lookupKeyWrite().

There are redundand checks, so for example, if in "2" something was
overlooked, we should be still safe, since anyway, when the master
writes the behavior is to don't care about what expireIfneeded()
returns.

This commit is related to  #1768, #1770, #2131.