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

Closes #598

No semantic changes.

In context of #2727

No semantic changes.

Needed for #2727

* update error messages
* rename variables
* add a few comments

Savepoint allows to partialy rollback a transaction. After
savepoint creation a transaction owner can rollback all changes applied
after the savepoint without rolling back the entire transaction.

Multiple savepoints can be created in each transaction. Rollback to
a savepoint cancels changes made after the savepoint, and deletes all
newer savepoints.

It is impossible to rollback to a savepoint from a substatements level,
different from the savepoint's one. For example, a transaction can not
rollback to a savepoint, created outside of a trigger, from a trigger body.

Closes #2025

Vinyl can not calculate bsize during transaction execution
because of DELETE and UPSERT in vinyl spaces with single index.

Move space bsize into MemtxSpace, because Vinyl can not calculate
it now.

In a future, Vinyl bsize can be calculated after dumps and
compactions, but never during transaction execution.

Address issues spotted by Alex Lyapunov:

 - Fix key part count computation in vy_read_interval_cmp[lr]()
   and vy_read_interval_should_merge() and add the corresponding
   test case.
 - Simplify comparison in vy_read_interval_cmp[lr]().
 - Improve comment to vy_tx_track().

See #2671

Fix misleading "C atomics not supported" when git submodules
are missing.

Closes #2088

Since #1265 tarantool is fully compatible with lua5.1.
Install /usr/bin/tarantool as /usr/bin/lua alternative.

Closes #2730

The check was accidentally broken by commit eb5cd536 ("vinyl: do not
track partial reads in tx manager"). Add a test case to avoid similar
screw-ups in future.

See #2716

There are two cases in the hermitage test that check gap locks - PMP
(predicate with many preceders) and G4 (anti-dependency cycles). As we
didn't have gap locks, we used get() to put a non-existent value to the
conflict set. Now we can use select(*) instead.

Currently, the conflict manager only tracks keys returned by the read
iterator, so Vinyl isn't really serializable as select() can return
phantom records, e.g.

  space: {10}, {20}, {30}, {40}, {50}

  Transaction 1                         Transaction 2
  -------------                         -------------
  box.begin()
  space:select({30}, {iterator='GE'})
  -- returns {30}, {40}, {50}
                                        box.begin()
                                        box.insert{35}
                                        box.insert{45}
                                        box.insert{55}
                                        box.commit()
  space:select({30}, {iterator='GE'})
  -- returns {30}, {35}, {40}, {45}, {50}, {55};
  -- were it serializable, the transaction would
  -- be sent to read view so that this select()
  -- would return the same set of values as the
  -- previous one
  box.commit()

Besides, tracking individual keys read by a transaction can be very
expensive from the memory consumption point of view: think of calling
select(*) on a big space.

So this patch makes the conflict manager track intervals instead of
individual keys. To achieve that it splits tx_manager->read_set in two:

 - vy_tx->read_set. Contains intervals read by a transaction. Needed to
   efficiently search intervals that should be merged with a new one.
   Intervals in this tree cannot intersect.

 - vy_index->read_set. Contains intervals read by all transaction from
   an index. Needed to efficiently search transactions that conflict
   with a write. Intervals can intersect.

When vy_tx_track() is called, it first looks up all intervals
intersecting with the new interval in vy_tx->read_set, removes them, and
extends the new interval to span them. Then it inserts the new interval
into both vy_index->read_set and vy_tx->read_set. The vy_index->read_set
is used on commit to send all transactions that read intervals modified
by the committed statement to read view.

Note, now we don't differentiate 'gaps', i.e. non-existent keys read by
a transaction. Gaps were used to avoid aborting a transaction if a
non-existent key read by it is deleted. We can't track gaps without
bloating the read set on select(*).

Closes #2671

Currently, this is done in each plain iterator (run, mem, txw, cache).
To handle the empty search key the same way as non-empty keys when
setting a gap lock, this needs to be handled in vy_read_iterator.

Needed for #2671