No semantic changes.

Needed for #2754

Needed for #2754

Needed for #2754

Needed for #2754

Minor renames

Travis images are broken by design.

Closes #2069

Ubuntu Trusty on Travis is buggy.

Fixes #2752

Needed for #946

If the iterator over a merge source was restored to a newer version of
the min key, we must not increment front_id, otherwise the source won't
be advanced on the next iteration, potentially resulting in the same key
returned twice by vy_merge_iterator_next_key(). In the long run, this is
likely to break the cache. Fix this and add an assert() checking that it
never happens.

While we are at it, remove loop from vy_read_iterator_merge_next_key()
that checks that the statement returned by vy_merge_iterator_next_key()
isn't the same as the statement returned to the user last time. The loop
condition should never evaluate to true, which is assured by the new
assert().

Fixes: 61ffe793 ("vinyl: fix read iterator restoration to a newer
version of the same key").

Throw error, if a new name for a fiber in Lua is too long.

Closes #2622

In case of an aggressive optimization coro_unwcontext might be inlined,
so it's should be good to add rax/eax to asm clobber list.

* remove obsolete comments from recovery.cc
* update example lua

* update tarantool man page
* cross-reference tarantool and tarantoolctl pages

The fallthrough attribute with a null statement serves as a fallthrough
statement. It hints to the compiler that a statement that falls through
to another case label, or user-defined label in a switch statement is
intentional and thus the -Wimplicit-fallthrough warning must not trigger.
The fallthrough attribute may appear at most once in each attribute list,
and may not be mixed with other attributes. It can only be used in a switch
statement (the compiler will issue an error otherwise), after a preceding
statement and before a logically succeeding case label, or user-defined
label.

https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/

Ubuntu Trusty on Travis is buggy.

Fixes #2752

Closes #2069

- Fix applier.cc/relay.cc dependencies. Relay/applier should not
  depend on box.cc. Add two separate flags to control timeout.
- Remove hardcoded REPLICATION_CFG_TIMEOUT.
- Fix replication_timeout value checking.

Follow up #2707

Signed-off-by: Roman Tsisyk <roman@tarantool.org>

Sometimes old relay instance couldn't be deleted yet before new
slave subscribe is there. For this case an invalid cfg error is
returned, and applier should reconnect after timeout.

Fixes #2277

Fixes #2707

Set applier reconnect delay and ack interval (hearthbeat interval) via
box.cfg replication_timeout parameter. Relay timeout (time interval
without hearthbeat messages) is four times bigger than replication_timeout,
so up to three hearthbeat messages can be skipped until connection to close.
Fixed #2708

After the read iterator selects the minimal key across all available
sources, it checks mutable sources for new statements using ->restore()
callback. If there is a new statement in a source, it uses it as the min
key provided it is *strictly* less than the current min key. If they are
equal, the min key isn't changed, but this is wrong, because the new
statement may be newer than the statement selected previously. If we
don't select it, we might end up with stale data in the cache. Fix this.

Since ->restore() is not used by the read iterator to start iteration
any more, we can remove the corresponding code from the cache iterator
->restore() callback. Although it might be tempting to simplify it even
more by doing a full lookup every time the cache version changes, as we
already do in case of memory and txw iterators, it doesn't seem to be a
sound idea, because the read iterator itself can change the cache
version on each iteration by inserting new elements into the cache, even
if there were no disk accesses.

We don't need to handle iterator restart in the ->restore() callback, so
we can remove the corresponding code. Also, let's reuse the start
iteration function for restoration, because the two cases are in fact
equivalent.

After the recent changes in the read iterator, the ->restore() callback
does not need to handle the case of iterator restart any more. Taking
this into account and keeping in mind that on-disk runs are immutable,
we can turn the run iterator ->restore() callback into no-op.

To avoid lookup in the memory tree, the memory iterator ->restore()
callback tries to walk from the current iterator position to the first
statement matching the restoration criteria. Such an optimization
complicates the restoration procedure beyond comprehension and makes it
extremely error prone. Ironically, all this complexity seems to be
pointless, because a change in the memory tree means either a disk
access, which is by orders of magnitudes more expensive than a memory
lookup, or an insertion of a new statement into the tree, which has
exactly the same complexity as a lookup. That said, let's rewrite the
restoration procedure so that it always does a full lookup in case the
version of the memory tree has changed.

Also, remove handling of iterator restart and the corresponding test
case as a ->restore() callback does not need to handle them any more.

Apart from restoring the iterator position in case the source changed,
the vy_stmt_iterator_iface->restore callback is also used for starting
iteration in vy_merge_iterator_next_key() even though next_key() can be
used instead. Let's rewrite the function so that it uses next_key()
instead of restore() where appropriate. This will allow us to simplify
restore() by making it handle nothing but iterator restoration.

The read iterator has to restart (i.e. reopen all its sources) from the
position last returned to the caller when the current range or the whole
range tree changes as a result of dump or compaction. To reposition the
iterator, we use vy_stmt_iterator_iface->restore callback, which was
initially designed to restore an individual merge source (txw, mem, or
cache) after a statement is added to or removed from it. Abusing the
callback like that complicates its implementation as well as the read
iterator itself. We can avoid that by simply reopening merge sources
with the proper key when we need to restart the read iterator.

The 'cleanup' callback is always called together with 'close'. The two
callbacks were separated long time ago, when vy_merge_iterator was used
for writing runs. There is no point in keeping them apart any more.

Closes #2746

Statement generated by the following piece code ({1, 1, 2}) isn't dumped
to the secondary index:

    s = box.schema.space.create('test', {engine = 'vinyl'})
    s:create_index('i1', {parts = {1, 'unsigned'}})
    s:create_index('i2', {parts = {2, 'unsigned'}})

    box.begin()
    s:insert{1, 1, 1}
    s:update(1, {{'+', 3, 1}})
    box.commit()

This happens, because UPDATE is replaced with DELETE + REPLACE in the
transaction log both of which have colun_mask = 0x04 (field #3 is
updated). These statements overwrite the original INSERT in the memory
index on commit, but they are not dumped, because their column_mask does
not intersect with the column mask of the secondary index (0x02).

To avoid that, the new statement (UPDATE = DELETE + REPLACE in this
case) must inherit the column mask of the overwritten statement
(REPLACE).

Fixes #2745

Emulate http://w3.impa.br/~diego/software/luasocket/tcp.html API

Needed for MobDebug

Closes #2727