A fix for Bug#987296 "cmake doesn't rebuild all files...
which include TARANTOOL_CONFIG".

Since the dependency between recompiled sources and tarantool
module config is not present anywhere in the code, cmake can
not track it.

Add an explicit object_depends to the relevant target.

Fix alignment of tarantool_mod function.

Tarantool/Box crashed during shutdown if a non running LUA fiber
was created.

Fiber garbage collection in Lua, initiated during shutdown,
was performed after the fiber subsystem was destroyed.

Additionally, fix a wrongly formulated assert which checks
that the fiber which is being cancelled has not been
cancelled already.

Darwin revealed a bug in our free_proc_title() function, which was
added to procitle.c to work well with valgrind: we free argv pointer
even if it wasn't allocated (none of PS_USE_CLOBBER_ARGV/PS_USE_CHANGE_ARGV
was set).

Don't free memory if it wasn't allocated.

Another issue is understanding why Darwin doesn't define
PS_USE_SETPROCTITLE and why our FreeBSD port didn't hit this bug.

User and developer guides was updated.
next_equal and prev_equal routines was added to index table.

Update .gitignore. Don't use tarantool encoding unless it's
necessary.

Now that we have unit-testing framework, cherry-pick mhash
unit tests from branch feature-hash-test.

A fix for bug https://bugs.launchpad.net/tarantool/+bug/790688
"ER_TUPLE_IS_RO should be more rare".

Rewrite the transaction processor to optimistically
perform changes in memory. In case of an error, transactions
are rolled back in order, reverse to the order of execution,
and gradually restore the original state of memory.
The wal writer therad orchestrates the rollback, by not
initiating it until all queries which entered the processing queue
before the error has occurred were not added to the rollback queue.

While in the state of rollback (i.e. collecting all requests
for rollback) new requests are not accepted into the processing
queue (see changes in wal_write()).

XXX: This patch makes dirty reads possible when we are in rollback,
since SELECTs do not enter the wal writer queue and can therefore
see changes which later will be rolled back. Since this is a
very rare situation, it's considered acceptable to fix this problem
in a separate patch (a separate bug will be reported).

Extend queue.h with STAILQ_SPLICE and STAILQ_REVERSE.
Test the new functions in a simple unit testing framework.

Fix a regression I introduced while refactoring
txn code with double unlock of txn->old_tuple.

We would assign txn->old_tuple before actually taking
a lock on it, then call txn_lock(), get an exception,
and in txn_rollback() unlock a lock which we didn't take.

This lead to an assertion failure or crash under concurrent
load, when the same tuple was updated from multiple connections.

* tnt_stream_rpl added
* console client replica mode added