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.

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.

Extract the WAL rotation into a separate function.

next_equal and prev_equal for lua box.index was added.

Merge common code in wal_write() and snapshot_write_row()
by introducing a structure to represent a single
snapshot or WAL row to be written.

No code changes.

iproto packages validation routine was added.

Continue code cleanup in log_io.m, remove more dead code.

Remove log_io_iter from snapshot IO. Do not use coroutines
and extra buffers. This opens the way to more agressive
buffering of snapshot IO, as compared to no buffering of WAL IO.

Cleanup work with eof/row markers. Remove unnecessary members
of log_io_class.

Fix a regression introduced by the yesterday's cleanup:

recover_wal() can return 0, -1, or 1:
0 - ok, eof read
-1 - error reading wal
1 - can't read eof marker from wal.

recover_remaining_wals() looks at this, and when doing final recovery
deletes wal which don't have eof marker (return value from recover_wal()
== 1).

Yesterday I mistakenly merged 0 and 1 return values into one.
Revert this part of the yesterday's patch.

On the same token, log_io_cursor_next() can't throw an exception,
ever. Take this into account and simplify code.

recover_remaining_wals() continues to stay a mess.