We needed to have txn_cleanup() only because a tuple
which was read in txn was used in fiber->io_vec.
Decouple txn and network I/O and make sure
we can commit/rollback txn whenever we like, regardless
of what is given to fiber->iovec.

@todo: perhaps we need to optimize performance
of port cleanup for big selects.

Rename classes in *.rl file.
Patch valgrind suppressions.

We don't use box_ prefix consistently, so don't use it at all.

Remove box_ prefix from box_tuple and box_txn.

Move out from box.m INSERT/UPDATE/SELECT/DELETE/CALL
implementation.

Cherry-picking code from txn-refine.
Remove an extra member in struct box_txn.
Rename txn->tuple to txn->new_tuple.

A fix for Bug#997602 incorrect read int64 field in connector-php
Use a correct value.

Conflicts:
	test/box/lua.result

Replication relay would actually *not* pick up .inprogress file,
and would continue looking for .xlog file every wal_dir_rescan_delay
seconds, and print errors in the error log.

As a side effect, the last record could be not replicated
for a long time if a master doesn't have any updates after
creating an .xlog file.

The fix is, when doing the recovery for replication relay (or for
local hot standby, or otherwise), is to look for .inprogress
file first, if it is found, use it/rename it.

No test case since so far we can't grep the error log for
things that should not occur in it.

A pre-requisite patch for a fix for Bug#955222
"Replication relay picks up .inprogress file":

Refactor the log_io_open logic to avoid
code duplication and allow for FILE to
be opened outside log_io_open* functions.

Start extracting recovery members/functions related to local
recovery to a separate data structure (recover_remaining_wals()
mess still remains).

recover() panics if things go wrong: don't
return any  value from it (until we fix it to not panic).

In recover() current_wal is always NULL, since we run
it right after start (or after establishing a connection
with a replica). Don't check for current_wal.

Don't produce a stupid error message "can't find WAL
with LSN:" when recovering from a snapshot, and a snapshot
is all we have in the data directory.

We (ab)use recover() and recover_remaining_wals() in
replication and in initial recovery, without doing the
abstraction homework, and this leads to convoluted
code and redundant logic.