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.

Signed-off-by: Konstantin Osipov <kostja@tarantool.org>

script_dir option defines path to a directory which contains the init.lua file.

A fix for https://bugs.launchpad.net/tarantool/+bug/992171
"SAVE SNAPSHOT process (dumper) does not respond to signals"

Reset the signal mask/handler after a fork to their defaults.
Make sure that when the snapshot dumper process is terminated
with a signal, we report it back to the user.

No test case since it would be hard to do a concurrent
test in our framework yet.

When salloc_init() fails, we call tarantool_free(),
which calls fiber_free(), which tries to destroy the fiber registry
hash, which has not been allocated.

Check that the hash has been allocated, before trying to destroy it.

Make the test more explicit.
Remove old/new config checking, which is currently pointless.

When the slab alloc arena is fully used, and we try to
truncate a space, we could crash, since

a) we never check return value of salloc()
b) we used to salloc() an iterator for truncate(), and
it would return NULL, and we would try to access it without a check.

The fix is:

- to throw exceptions directly from salloc()
- to not use salloc() for iterators, since we still should
be able to truncate a namespace when the slab alloc arena is
full.

Fix bug
https://bugs.launchpad.net/tarantool/+bug/983094
"Valgrind tests were broken by WAL writer patch"

Keep track of WAL files opened for write
in recovery

Extend atfork handler to clear the wals,
to avoid collision with reuse of recovery
to save a snapshot.

Move some WAL-specific configuration settings
from wal_class to recovery, to avoid layers
of indirection when doing RELOAD CONFIGURATION

Fix brokken static compilation of the client (we'll have
to find another solution for Darwin).

Make snap_io_rate_limit and io_collect_interval dynamic.
Add a test case.
Update the user guide.