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.

Needed for #1906

So that vy_tx does not depend on vy_cursor.

Needed for #1906

Needed for #1906

We can't move vy_index_new() to a separate file right now, because it
depends on vy_env and we can't just replace vy_env with vy_index_env and
vy_cache_env there, because the function is called from outside vinyl.c.
To deal with that, let's introduce wrappers around vy_index_new() and
vy_index_delete(), vy_new_index() and vy_delete_index(), which are vinyl
C API functions that simply call the internal functions with appropriate
arguments. Also, remove vy_index_ref() and vy_index_unref() from the C
API, as they are not really necessary.

Needed for #1906

 - Introduce vy_index_env hosting fields common to all indexes and
   replace vy_index->env with it.
 - Use a callback to trigger async upsert squashing.
 - Pass vy_env or vy_schedule in function arguments instead of using
   index->env.

Needed for #1906

So that we can remove vy_env reference from internal Vinyl structures.

Needed for #1906

Needed for #944

alter: remove snprintf from func_def_new_from_tuple

Now vinyl's rollback to TX savepoint doesn't work in case when one
TX has several statements modifying the same key.

A simple example is presented in gh ticket 2589.

Fix it.

Add a big test that compares vinyl with memtx in case of many
failing (catched with pcall) statements done in a transaction.

Fixes #2589

Now if a TX (in vinyl) changes the same key again, it uses
previously created struct txv and updates the tuple in it.
Therefore the change is not added to the transaction log; instead,
the old entry in the log is updated.

At the same time, the order of TX log is important, especially when
there are several indexes in a vinyl space: tx_prepare traverses
TX log, determines the beginning of a tarantool statement (that
could consist of several vinyl statements) and behave with several
conjuncted txvs as a whole.

Fix it by leaving old txv and always creating new txv.

Fixes #2577

- don't reference the upserted tuple twice in vy_tx_set(..)
- handle txv allocaion error properly in vy_tx_et(..)

The return value of txv_new was not checked.

Instead introduce vy_run_env_enable_coio(), which starts reader threads,
and make vy_run_iterator automatically switch to coio if reader threads
are running. With this patch, vy_read_iterator doesn't need a pointer to
vy_env to add a run as a source, only vy_run_env.

While we are at it, cleanup vy_conf a bit.

Needed for #1906

vy_run_write_page() doesn't take a reference to last_stmt, because it
assumes that the write iterator guarantees it won't be deleted until
'next' is called again. The iterator does pin a statement if it is read
from a run file - see vy_write_iterator_set_tuple() - however there's a
case when the last returned statement can go away under us. This will
happen if the iterator is used for major compaction and the last source
statement is a DELETE. In this case the iterator will unreference the
last statement it returned to the caller, take a reference to the DELETE
instead, but won't return the DELETE - see vy_write_iterator_next(). As
a result, the caller, i.e. vy_run_write_page(), will hit use-after-free
on an attempt to read last_stmt.

To fix this bug, let's make vy_run_write_page() take a reference to
last_stmt as it used to before the write iterator was reworked. A test
case will be added later, after all iterator-related issues have been
fixed.

Closes #2578

Iconv is a library to convert a sequence of characters in one
character encoding to a sequence of characters in another character
encoding. Example below converts utf-16 big endian string into utf-8
string:

    convertor = require('iconv').new('UTF-16BE', 'UTF-8')
    converted_string = convertor(source_string)

Closes #2587

vy_task_dump_new() deletes empty in-memory trees right away, but
doesn't increment vy_index->mem_list_version, which may result in
a read iterator crash accessing a deleted vy_mem.

Now open MP sort is used for any size of an array.
For small arrays it's an overkill and even can cause overhead
due to thread pool creation.

Invoke open MP sort only for big arrays and use old good
single-thread qsort for small arrays.

Fix #2431

Print original uri as is if it doesn't contain sensitive
information.

Closes #2292

Currently, quota (and some global stats) are adjusted in
vy_index_commit_upsert(), vy_tx_prepare(), and vy_tx_commit(),
which entails dependency of vy_index and tx_manager on vy_env.
Let's move this code to the upper level, i.e. to vy_prepare()
and vy_commit().

Needed for #1906

Remove box.info.vinyl().performance.{tx_rlb,tx_conflict}. Instead add
'tx' section to box.info.vinyl() with the following counters:

 - 'active': number of active transactions
 - 'commit': number of committed transactions
 - 'rollback': number of rolled back transactions
 - 'conflict': number of transactions aborted on conflict

Apart from improving vinyl statistics, this patch also pursues one more
goal: removing dependency of vy_tx and tx_manager on vy_env, which is
needed to move them to a separate source file.

Needed for #1662 #1906

It belongs there, really.

Currently, during local recovery, an index is added to the
scheduler from vy_index_recover(), which makes this function
depend on index->env->scheduler. Let's postpone addition to
vy_index_commit_create() as we do when vinyl is online.

Needed for #1906

Needed to remove dependency of vy_index on struct txv.

Needed for #1906

Before this patch, the new space, created by alter specification,
would be put into space cache only after successful WAL write.

This behaviour is not linearizable: on a replica, the WAL is
played sequentially, and the order of events could differ from the
master.

Besides, it could crash, as demonstrated in gh-2074 test case.

Since we use a cascading rollback for all transactions on WAL
write error, it's OK to put a space into space cache
before WAL write, so that the new transactions apply to the new
space.

This patch does exactly that.

All subsequent requests are executed against the new space.

This patch also removes on_replace trigger in the old space, since
all checks against the new tuple format are performed using the new
space.

Fixes #2074.

 Do not leak input buffer references on an incorrect packet.

 Before this patch, in case of incorrect packet, in->rpos was never
 advanced, creating an eternal request and blocked input buffer.

 A follow up on gh-1654.

closes gh-2576

* update comments
* add a test case for altering a primary key on the fly
* rename AddIndex to CreateIndex
* factor out common code into a function

MoveIndex operation is used to move an existing index from the old space
to the new one. Semantically it's a no-op.

RebuildIndex is introduced for case when essential index properties are
changed, so it is necessary to drop the old index and create a new one in
its place in the new space.

AlterSpaceOp::prepare() is removed: all checks are moved to
on_replace trigger in _index system space from it.
All checks are done before any alter operation is created.

Necessary for gh-2074 and gh-1796.

Move the check which decides on an alter strategy whenever
a row in _index space is changed, from AlterSpaceOp::preapre()
to on_replace trigger on _index space.

The check chooses between two options: a heavy-weight index rebuild,
invoked when index definition, such as key parts, is changed, vs.
lightweight modify, invoked when index name or minor options are
modified..

Before this patch, index alteration creates a pair of operations
(DropIndex + AddIndex) in all cases, but later
replaces two operations with one at AlterSpaceOp::prepare() phase.

This is bad by several reasons:

- it's done while traversing of a linked list of operations,
  and it changes the list being traversed.

- an order in the list of operations is required for this
to work: drop must precede add.

- needless allocation and deallocation of operations makes the logic
  unnecessarily complex.

Necessary for gh-1796.