Scripting: simpler reply buffer creation in luaRedisGenericCommand().

It if faster to just create the string with a single sdsnewlen() call.
If c->bufpos is zero, the call will simply be like sdsemtpy().
Define HAVE_ATOMIC for clang.
Scripting: luaRedisGenericCommand() fast path for buffer-only replies.

When the reply is only contained in the client static output buffer, use
a fast path avoiding the dynamic allocation of an SDS string to
concatenate the client reply objects.
Scripting: replace tolower() with faster code in evalGenericCommand().

The function showed up consuming a non trivial amount of time in the
profiler output. After this change benchmarking gives a 6% speed
improvement that can be consistently measured.
Fixed missing c->bufpos reset in luaRedisGenericCommand().

Bug introduced when adding a fast path to avoid copying the reply buffer
for small replies that fit into the client static buffer.
Scripting: cache argv in luaRedisGenericCommand().

~ 4% consistently measured speed improvement.
Scripting: don't call lua_gc() after Lua script run.

Calling lua_gc() after every script execution is too expensive, and
apparently does not make the execution smoother: the same peak latency
was measured before and after the commit.

This change accounts for scripts execution speedup in the order of 10%.
Scripting: Use faster API for Lua client c->argv creation.

Replace the three calls to Lua API lua_tostring, lua_lua_strlen,
and lua_isstring, with a single call to lua_tolstring.

~ 5% consistent speed gain measured.
Scripting: objects caching for Lua c->argv creation.

Reusing small objects when possible is a major speedup under certain
conditions, since it is able to avoid the malloc/free pattern that
otherwise is performed for every argument in the client command vector.
Test: handle new osx 'leaks' error.

Sometimes the process is still there but no longer in a state that can
be checked (after being killed). This used to happen after a call to
SHUTDOWN NOSAVE in the scripting unit, causing a false positive.
Scripting test: check that Lua can call commands rewirting argv.

SPOP, tested in the new test, is among the commands rewritng the
client->argv argument vector (it gets rewritten as SREM) for command
replication purposes.

Because of recent optimizations to client->argv caching in the context
of the Lua internal Redis client, it is important to test for SPOP to be
callable from Lua without bad effects to the other commands.
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