(https://blueprints.launchpad.net/tarantool/+spec/lua-builtin-size-of-subtree)

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

The field made optional by the previous refactoring
patch were used for monitoring.
Put them back.

Conflicts:
	src/log_io.m

Extract struct recovery_state members which are used
only when replication is on to struct remote.

No actual code changes, simply split a big file in two.

No code changes.

Do not use buffered file I/O which doesn't
give a precise account of failure, when it happens.

Instead, batch writes to WAL or SNAP files and
write batches using writev(). If writev() fails,
we can accurately evaluate which requests (those that
belong to the batch) were not written to disk.

In case of a partial write, rollback the failed requests,
and seek back to the end of the last fully written
request.

To support writev() and IO with file descriptors,
implement nio library, which provides a set of
EINTR- and error log- aware wrappers around syscalls.

* stream write_request virtual method added
* initial implementation of wal-cat, wal-player in console client