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>

Apply documentation edits suggested by Peter Gulutzan.
Fix 'relink' target to correctlly build target.db.