Check that:

 - Empty spaces are recovered correctly.
 - Data is restored fully, for every index.
 - In-memory data is not lost.

Needed for #2397

 - Make vinyl/split_coalesce restart the server and check the space
   content after splitting and coalescing ranges.
 - Do not split ranges in vinyl/recover test, as it is now tested by
   vinyl/split_coalesce test.

Needed for #2397

vinyl/coalesce already tests range splitting, no need in
a separate test case.

Needed for #2397

On space alter (index create/drop) new_space->truncate_count is left
unset, which breaks vinyl recovery logic: in vinyl we assume that if
index->truncate_count (restored from vylog) > space->truncate_count,
the space will be truncated and so there's no need in applying a WAL
row (see vy_is_committed_one()). So if an index is dropped or created
after truncate, vinyl won't apply statements for it on recovery.

Closes #2615

An index can be dropped and then recreated with the same space/index id.
To discriminate between different incarnations of the same index during
recovery, we use index LSN stored in index options, as it is supposed to
be unique. However, the uniqueness property doesn't always hold:

 - If two indexes are created from different fibers, they might receive
   the same LSN.

 - If an index is created by inserting a record into _index system space
   directly, without using the public API, as it is the case in case of
   logical backup, its LSN might conflict with the LSN of an existing
   index or a previous incarnation of the same index stored in vylog.

These exceptions can result in unrecoverable errors during local
recovery, like this one:

  F> can't initialize storage: Invalid VYLOG file: Duplicate index id 3

Besides, storing LSN in index options is ugly, because LSN isn't a
user-defined option - it's a part of the implementation.

To fix this issues, let's use the LSN passed to Index::commitCreate,
i.e. the actual LSN received by the row that created the index. There's
one problem though: snapshot rows don't store LSNs. However, it doesn't
mean we can't find the index in vylog corresponding to a snapshot row:
we just need to look up the index by space_id/index_id instead of LSN
and then compare the snapshot LSN with the LSN of the last index
incarnation stored in vylog - if the latter turns out to be less, then
we need to load the index, otherwise the index is going to be dropped
and we need to load a dummy index. For more details, see the comment to
vy_recovery_load_index().

Another issue that needs a clarification is backward compatibility. The
thing is the LSN written to the index options lags behind the actual LSN
assigned to the row that created the index by 1. So to preserve backward
compatibility, we use LSN from index options for legacy indexes that
have it, while for indexes created after this patch we don't store LSN
in index options (set it to 0), neither do we use it on recovery (use
row LSN instead).

Closes #2536

Currently, 0 is passed to Index::commitCreate as index LSN during
initial join. To stop using index_opts->lsn for identifying indexes in
Vinyl, we need a unique LSN. So let's install a dummy journal to assign
fake unique LSNs for rows received on initial join.

Needed for #2536

So that we could use it instead of index_opts::lsn.

On initial recovery pass the snapshot LSN instead as we don't store LSNs
in memtx snapshot.

Needed for #2536

Closes #2569

Implement tuple_arena_create method to initialize tuple arena and
quota. This method further will be used to initialize both
memtx and vinyl arenas.

Write a test showing the limit of vinyl statements size.

Part of #2569

Now if an error happens during the first tuple push from port to
obuf, the port is not actually destroyed - only the first tuple is
unreferenced.

I believe that port dump must not free any data at all, then once
a user creates a port he must take the ownership and destroy it in
the end of usage. That would simplify the user code, especially C++.

Simplify port_dump function and destroy a port in the code that
creates the port.

LuaRocks requires openssl and curl in order to download
manifest from rocks.tarantool.org.

Fixes #2612

Fix compatibility with original tarantool/http client.

Follow up #2530

See https://github.com/tarantool/doc/issues/235#issuecomment-313196971

Closes #2605

coio_call() must not release stack until all work is done.
Repeat yielding until task is completed in a worker thread.

Fixes #2604

Usage:

    tarantoolctl rocks install ROCK - install a rock
    tarantoolctl rocks remove ROCK - remove a rock
    tarantoolctl rocks show ROCK - show information about an installed rock
    tarantoolctl rocks search PATTERN - search repository for rocks
    tarantoolctl rocks list - list all installed rocks

There are no other commands, options, configuration files. Our official
repository (http://rocks.tarantool.org) works out of the box. All rocks
are installed to ${PWD}/.rocks directory to support separate rocks trees
per project, as proposed by #2067. Rockspec can use "tarantool >= 1.7.x"
inside dependencies = {} block to depend on a specific Tarantool version.

LuaRocks has been slightly hacked to support custom configuration
via site_config.lua. There are no other changes in the upstream code.
It is not a fork and it isn't going to be a fork. All formats, layouts
and rockspecs are 100% compatible with the upstream LuaRocks 2017-07-10.

This feature intentionally doesn't have CMake option to disable it,
because it should be provided on all available platforms out of the box.

Other changes:

 * Add ${PWD}/.rocks to default package.path/package.cpath
 * Hack tarantoolctl to display subcommands in --help.
   Currently command line arguments handling are not perfect, but
   it can be fixed only by a new argparse implementation.

Closes #2067

A part of #1451

No semantic changes.

Needed for #1451

No semantic changes.

Needed for #1451

No semantic changes.

Needed for #1451

No semantic changes.

Needed for #1451

Follow up 6015e0df

Closes #944

Do not use BOX_NAME_MAX as size of static buffers. Further it will
be strongly increased.

Part of #944

This flag is needed to skip records corresponding to dropped and
incomplete runs on recovery, because given VY_LOG_CREATE_RUN the
vy_recovery_iterate() callback can't tell if the run is used or
going to be dropped. This flag needlessly complicates the code of
vy_recovery_iterate(), which is supposed to simply replay all records
recovered from the log, not try to be smart. Let's get rid of it and
instead add a hint to vy_log_record indicating that a run created by
VY_LOG_CREATE_RUN is going to be dropped.

vy_prepare_truncate_space() doesn't need to make directories for
truncated indexes - they must already exist as the indexes were
created. It just needs to create initial range for each of them.
Factor out vy_index_init_range_tree() out of vy_index_create()
and use it instead where appropriate.

We have vy_recovery_lookup_index() function to look up an index in a
recovery context by id and vy_recovery_iterate_index() to iterate over
ranges, runs, and slices of a found index. vy_recovery_lookup_index()
used to be a part of vy_recovery_iterate_index() and was factored out
when index logging was moved to be called after WAL write, from
vy_index_commit_create(), because during recovery we need to check if an
index creation record was flushed to vylog before restart - currently we
do it by trying to look it up in the recovery context.

To stop using index lsn as vylog index id and remove lsn from index
options, I'm planning to make the function loading an index from vylog
advance an internal vylog counter so that the next time it is called it
loads a newer incarnation of the same index. vy_recovery_lookup_index()
doesn't fit this concept. So I introduce vy_recovery_load_index() that
calls vy_recovery_lookup_index() and vy_recovery_iterate_index()
internally and make the two functions private to vylog. To deal with
indexes not logged due to vylog errors, I introduce a per index flag,
vy_index->is_committed, which is set if the index record was flushed to
vylog - the same approach is already used to handle index drop (see
vy_index_commit_drop()).

Closes #2535

Now if a prepared transaction is aborted, it expects to be the
latest prepared TX in TX manager. It's not true in two cases:

- The transaction failed during preparation. The TX is in partially
  prepared state and must rollback all the changes it made in mems
  but the preparation was not finished and thus the TX could not be
  considered as the latest in TX manager.

- It's a cascading rollback with more than on TX. It would be
  graceful for the latest aborted TX to set the previous TX as
  the latest after the abortion. But the TX does not know the
  previous prepared TX and simply set to NULL appropriate pointer;
  when the time comes for the previous TX to be aborted it
  does not see itself as the latest.

The TX must not expect itself to be the latest but must handle
the last_prepared_tx pointer only if it is the latest.

Fix it and add tests.

Fix #2588 (case 1)
Fix #2591 (case 2)

Better safe than sorry.
@todo@: rewrite to send an error for reporting to iproto thread instead.

In scope of gh-2507.

Part of the #2507

dh_systemd_enable called BEFORE dh_install, which installs file(s)
(tarantool.service), required for dh_systemd_enable. A quick workaround
is to symlink tarantool.service into debian/ directory.

Issue appeared only in cdbs comming with Debian 9.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864489

Thanks for Alexander Sbitnev

+ Fix inconsistent debian/changelog and debian/control.