Sentinel: generate +config-update-from event when a new config is received.

This event makes clear, before the switch-master event is generated,
that a Sentinel received a configuration update from another Sentinel.
Sentinel: log when a failover will be attempted again.

When a Sentinel performs a failover (successful or not), or when a
Sentinel votes for a different Sentinel trying to start a failover, it
sets a min delay before it will try to get elected for a failover.

While not strictly needed, because if multiple Sentinels will try
to failover the same master at the same time, only one configuration
will eventually win, this serialization is practically very useful.
Normal failovers are cleaner: one Sentinel starts to failover, the
others update their config when the Sentinel performing the failover
is able to get the selected slave to move from the role of slave to the
one of master.

However currently this timeout was implicit, so users could see
Sentinels not reacting, after a failed failover, for some time, without
giving any feedback in the logs to the poor sysadmin waiting for clues.

This commit makes Sentinels more verbose about the delay: when a master
is down and a failover attempt is not performed because the delay has
still not elaped, something like that will be logged:

    Next failover delay: I will not start a failover
    before Thu May  8 16:48:59 2014
Add dynamic command loading

We can now add custom commands to Redis without recompiling.

Add commands by creating a shared library containing:
    - a table exporting your command definitions
      - (exactly the same as redisCommandTable has always been)
    - a string defining the name of your module

You can add modules in redis.conf with
    "module-add [module.so]"
or on the command line with
    redis-server --module-add module.so
or at runtime with
    "CONFIG SET MODULE-ADD [module.so]"

If you add a module twice, the second time will:
  - load the new module
  - unload the previous module
  - overwrite commands from the old module with
    commands in the new module
  - reset per-command stats/counters for each of
    the newly re-added commands

(Note: Any commands in the old module but not
in the new module will stick around.  To remove a command you
should keep it in your module and just give it a
noop definition or alias it to something simple like the
ping command.)

(Note: There is no way to remove or unload
a module.  You can only add modules and reload existing
modules by re-adding them.  To remove a module, restart
Redis.)

(Note: Running a master-replica or cluster setup with Redis
instances not containing the same set of modules will break
horribly.  Either fully distribute your modules or don't
use modules with replicated Redis.)

This commit contains these changes:
    - Make sure the Redis command table ends with a NULL entry
    - Rename populateCommandTable() to populateCommand(), and
      make it only process one command per invocation.
    - Replace all numcommands calculations with redisCommands.length.
    - Replace usage of redisCommandTable with redisCommands.table.
    - Replace the server startup call to populateCommandTable()
      with a call to loadDynamicCommands(NULL).  When given NULL,
      loadDynamicCommands reads the command table from the
      redis-server executable instead of an externally loaded module.
      Yes, that means the same mechanism used to import new commands
      from external modules bootstraps built-in commands too.
    - Add new INFO MODULES section to output all loaded
      modules, with their names, library filenames, original
      load timestamp, most recent load timestamp (for when
      modules are reloaded with CONFIG SET), and the list of
      commands the module provides.  Note: The redis-server itself
      is processed as a module, so it shows up as module <builtin>.
    - Add new configuration option 'module-add'.
    - Add new CONFIG SET option 'module-add'.

Example output of INFO MODULES:
    127.0.0.1:6379> info modules
    # Modules
    module_demo_ping:filename=ping.so,first_loaded=0,last_loaded=1395789529,commands=poong,pooooong,pooong
    module_<builtin>:filename=<builtin>,first_loaded=0,last_loaded=0,commands=get,set,setnx,setex,psetex,append,strlen,del,exists,setbit,getbit,setrange,getrange,substr,incr,decr,mget,rpush,lpush,rpushx,lpushx,linsert,rpop,lpop,brpop,brpoplpush,blpop,llen,lindex,lset,lrange,ltrim,lrem,rpoplpush,sadd,srem,smove,sismember,scard,spop,srandmember,sinter,sinterstore,sunion,sunionstore,sdiff,sdiffstore,smembers,sscan,zadd,zincrby,zrem,zremrangebyscore,zremrangebyrank,zunionstore,zinterstore,zrange,zrangebyscore,zrevrangebyscore,zcount,zrevrange,zcard,zscore,zrank,zrevrank,zscan,hset,hsetnx,hget,hmset,hmget,hincrby,hincrbyfloat,hdel,hlen,hkeys,hvals,hgetall,hexists,hscan,incrby,decrby,incrbyfloat,getset,mset,msetnx,randomkey,select,move,rename,renamenx,expire,expireat,pexpire,pexpireat,keys,scan,dbsize,auth,ping,echo,save,bgsave,bgrewriteaof,shutdown,lastsave,type,multi,exec,discard,sync,psync,replconf,flushdb,flushall,sort,info,monitor,ttl,pttl,persist,slaveof,debug,config,subscribe,unsubscribe,psubscribe,punsubscribe,publish,pubsub,watch,unwatch,cluster,restore,restore-asking,migrate,asking,readonly,readwrite,dump,object,client,eval,evalsha,slowlog,script,time,bitop,bitcount,bitpos,wait

(Note: {first,last}_loaded of 0 means it was loaded at startup from a configuration
directive or command line argument.  If loaded != 0, then the module
was evaluated after the server started using CONFIG SET MODULE-ADD [module.so])

Backported from unstable to 2.8.8.  Fixed conflicts:
	src/config.c
	src/redis.c
Fix module reloading

Allow modules to be reloaded with the same filename.  Previously,
due to dlopen refcounting, loading the same module twice, even
if updated, wouldn't actually reload any module contents.

Now modules are loaded, checked for name, checked for existing
module, if existing module found, old module is unloaded, current
module is unloaded (at this point, refcount = 0), then the process
is re-started to load the module again, this time so it gets reloaded
because the prior refcount is now zero.

Got it?

Also fix a Linux compatability issue by removing RTLD_FIRST.
Remove unnecessary malloc

Hey, look, we're using c99 and can do things like this now.
Add redisModule struct with associated operations

Now we store incoming module definitions in a struct, giving
us room to collect all our details (except the command table)
in one place.

Of note, now modules can define initilization functions
and cleanup functions for load/unload symmetry.

Also, there's a version field to detect when you're running a module
built against a different version of Redis than you are currently
running.  The module will still load, but you'll get a warning
about the mismatched versions.

Also, added proper cleanup and closing/unloading of all modules
on shutdown.
Add number of loaded modules to INFO SERVER

Provide a quick entry point to look for debugging information. If
loaded_modules > 0, then any breakage is potentially the fault of
externally loaded modules.

Note: we are reporting on externally loaded modules.  The <builtin>
module isn't reported in the size.  loaded_modules gets incremented
for each module name loaded by configuration parameter 'module-add'
or by runtime 'CONFIG SET MODULE-ADD'.

When loaded_modules:0, INFO MODULES will still have output.  The
output will be the <builtin> module with all default Redis commands.
Add strict module version config directive

By default, Dynamic Redis now only allows exact matches
between the running Redis version and the version of Redis
a module was compiled against.

You can disable this check and run modules compiled against different
versions of Redis by setting config parameter 'module-strict' to 'no'.

The default setting is: module-strict yes.

You may also "CONFIG SET module-strict no" at runtime if you need to
temporarily enable or disable module version checking.
Add module type definition

We may have different types of modules in the future
instead of only loadable commands.  Require all modules to tell
us their purpose.

Effect of defining a module as type REDIS_MODULE_COMMAND:
we load redisCommandTable[] from the module.
Add module version field and track on server

Modules should have their own independent versions so we can
debug future module problems by people running different versions
of the same thing.  (Or the inevitable "But I'm not running version
0.3, I'm running version 5.3!"  Then once you look, they are actually
running version 0.001.)

Also improve INFO MODULES output to include the module version and the
version of Redis the module compiled against.

New output from INFO MODULES for a custom module:
module_test_poong:filename=ping.so,compiled_against=2.9.11,module_version=3bob,first_loaded=0,last_loaded=1396025761,commands=poong,pooooong,pooong,pinger

More Information = More Good
Dynamic Redis 2.8.8-0.5
Add "dynamic.h" providing prototypes for internals

We need some functions exposed in modules, but they aren't
in any existing headers.

Instead of adding them to headers, we just create a new header
and add anything to it we need specifically for modules that
Redis itself doesn't necessarily need for compilation.
Remove static linkage from some zset functions

We need to use zee zsets elsewhere.
Dynamic Redis 2.8.8-0.5.1

Changes:
  - export some internal Redis functiosns so we can use them in modules
  - Add dynamic redis version define for conditionally compiling module features
Fix zzlFirstInRange prototype

The implementation changed with the implementation of ZRANGEBYLEX
into now accepting a pointer instead of the struct directly.
Add coarse feature flags for compile-time use

Some functions and features of modules need to be disabled
based on the presence or absense of things.  Let's try feature
flags instead of using floating versions.
Dynamic Redis 2.8.9-0.5.2

Changes:
    - Based on Redis 2.8.9
      - Includes: PF (HyperLogLog) and ZRANGEBYLEX commands
    - Also includes new Dynamic Redis preprocessor feature flags

Conflicts:
	src/version.h