Upload tarballs of alpha and beta tarantool versions (*.0 and *.1
branches) into 2x (3x, 4x...) buckets. See more details about the
release process in the documentation: [1].

[1]: https://tarantool.io/en/doc/2.0/dev_guide/release_management/

The reason of the failures is TLSv1.0/TLSv1.1 brownout on the PyPI side,
see [1] for more information.

[1]: pypa/packaging-problems#130

People use console for tarantool monitoring. Something we never
anticipated when added it. Connected and disconnected messages
which happen every second pollute the log.

Try to fix coverage.

- Remove old versions of Fedora and Ubuntu
- Add Fedora 26 and Fedora 27

Crash details on SIGSEGV added

* more details printed in fatal signals handler
* dump x86-64 registers on crash
* registers dump is disabled for non-linux platforms

A DNS issue can raise a SystemError, applier should handle this error

Fixed #3001

Initialize admin user access to universe access on instance start.

Applier must not update the replication lag upon receiving a packet
containing an error, because those packets don't have timestamps.

Closes #2965

Remove `message` field from blacklist, because JSON and plain
loggers are mutually exclusive.

Fixes #2923

On disconnect applier input buffer can contain some unparsed data, clear
this.

Fixes #2932

Implement ':isfunction()' test function  in Tap testing framework
that checks whether type of an argument is 'function'.

Closes #1859

If the index was dropped during dump, we abort the dump task so as not
to log information about zombie indexes to the vylog. However, we should
still notify the scheduler that its memory can be released by calling
vy_scheduler_complete_dump(). If we don't, lsregion won't be truncated
until another index is dumped. If there is no other vinyl indexes out
there or all other indexes have already been dumped, memory will never
be freed.

On debug builds, it will result in the following assertion failure:

  vy_scheduler.c:1319: vy_scheduler_peek_dump: Assertion `scheduler->dump_task_count > 0' failed.

Start applier->writer fiber only after SUBSCRIBE.
Otherwiser writer will send ACK during FINAL JOIN and break
replication protocol.

Fixes #2726

Make sure the master receives an ack from the replica and performs
garbage collection before checking the checkpoint count.

We remove old xlog files as soon as we have sent them to all replicas.
However, the fact that we have successfully sent something to a replica
doesn't necessarily mean the replica will have received it. If a replica
fails to apply a row (for instance, it is out of memory), replication
will stop, but the data files have already been deleted on the master so
that when the replica is back online, the master won't find appropriate
xlog to feed to the replica and replication will stop again.

The user visible effect is the following error message in the log and in
the replica status:

  Missing .xlog file between LSN 306 {1: 306} and 311 {1: 311}

There is no way to recover from this but to re-bootstrap the replica
from scratch.

The issue was introduced by commit ba09475f ("replica: advance gc
state only when xlog is closed"), which targeted at making the status
update procedure as lightweight and fast as possible and so moved
gc_consumer_advance() from tx_status_update() to a special gc message.
A gc message is created and sent to TX as soon as an xlog is relayed.
Let's rework this so that gc messages are appended to a special queue
first and scheduled only when the relay receives the receipt
confirmation from the replica.

Closes #2825

Engine callbacks that perform garbage collection may sleep, because they
use coio for removing files to avoid blocking the TX thread. If garbage
collection is called concurrently from different fibers (e.g. from relay
fibers), we may attempt to delete the same file multiple times. What is
worse xdir_collect_garbage(), used by engine callbacks to remove files,
isn't safe against concurrent execution - it first unlinks a file via
coio, which involves a yield, and only then removes the corresponding
vclock from the directory index. This opens a race window for another
fiber to read the same clock and yield, in the interim the vclock can be
freed by the first fiber:

  #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
  #1  0x00007f105ceda3fa in __GI_abort () at abort.c:89
  #2  0x000055e4c03f4a3d in sig_fatal_cb (signo=11) at main.cc:184
  #3  <signal handler called>
  #4  0x000055e4c066907a in vclockset_remove (rbtree=0x55e4c1010e58, node=0x55e4c1023d20) at box/vclock.c:215
  #5  0x000055e4c06256af in xdir_collect_garbage (dir=0x55e4c1010e28, signature=342, use_coio=true) at box/xlog.c:620
  #6  0x000055e4c0417dcc in memtx_engine_collect_garbage (engine=0x55e4c1010df0, lsn=342) at box/memtx_engine.c:784
  #7  0x000055e4c0414dbf in engine_collect_garbage (lsn=342) at box/engine.c:155
  #8  0x000055e4c04a36c7 in gc_run () at box/gc.c:192
  #9  0x000055e4c04a38f2 in gc_consumer_advance (consumer=0x55e4c1021360, signature=342) at box/gc.c:262
  #10 0x000055e4c04b4da8 in tx_gc_advance (msg=0x7f1028000aa0) at box/relay.cc:250
  #11 0x000055e4c04eb854 in cmsg_deliver (msg=0x7f1028000aa0) at cbus.c:353
  #12 0x000055e4c04ec871 in fiber_pool_f (ap=0x7f1056800ec0) at fiber_pool.c:64
  #13 0x000055e4c03f4784 in fiber_cxx_invoke(fiber_func, typedef __va_list_tag __va_list_tag *) (f=0x55e4c04ec6d4 <fiber_pool_f>, ap=0x7f1056800ec0) at fiber.h:665
  #14 0x000055e4c04e6816 in fiber_loop (data=0x0) at fiber.c:631
  #15 0x000055e4c0687dab in coro_init () at /home/vlad/src/tarantool/third_party/coro/coro.c:110

Fix this by serializing concurrent execution of garbage collection
callbacks with a latch.

Currently, box.schema.upgrade() is called automatically after box.cfg()
if the upgrade is considered safe (currently, only upgrade to 1.7.5 is
"safe"). However, no upgrade is safe in case replication is configured,
because it can easily result in replication conflicts. Let's disable
auto upgrade if the 'replication' configuration option is set.

Closes #2886

Before commit 29d00dca ("alter: forbid to drop space with truncate
record") a space record was removed before the corresponding record in
the _truncate system space so we should disable the check that the space
being dropped doesn't have a record in _truncate in case we are
recovering data generated by tarantool < 1.7.6.

Closes #2909

Bloom filter depends on hash function, which depends on ICU
version, which may vary.

+ Don't use id=0 for collations

Follow up #2649

Fix tuple_hash_field() to handle the following cases properly:

 - Nullable string field (crash in vinyl on dump).
 - Scalar field with collation enabled (crash in memtx hash index).

Add corresponding test cases.

First, unique but nullable indexes are not rebuilt when the primary key
is altered although they should be, because they can contain multiple
NULLs. Second, when rebuilding such indexes we use a wrong key def
(index_def->key_def instead of cmp_def), which results in lost stable
order after recovery. Fix both these issues and add a test case.

Needed to check if the key definition loaded from vylog to send initial
data to a replica has the collation properly recovered.

It isn't stored currently, but this doesn't break anything, because the
primary key, which is the only key whose definition is used after having
been loaded from vylog, can't be nullable. Let's store it there just in
case. Update the vinyl/layout test to check that.

Collations were disabled in vinyl by commmit 2097908f ("Fix
collation test on some platforms and disable collation in vinyl"),
because a key_def referencing a collation could not be loaded from
vylog on recovery (collation objects are created after vylog is
recovered). Now, it isn't a problem anymore, because the decoding
procedure, key_def_decode_parts(), deals with struct key_part_def,
which references a collation by id and hence doesn't need a collation
object to be created. So we can enable collations in vinyl.

This patch partially reverts the aforementioned commit (it can't
do full revert, because that commit also fixed some tests along
the way).

Closes #2822

We can't use key_def_decode_parts() when recovering vylog if key_def has
a collation, because vylog is recovered before the snapshot, i.e. when
collation objects haven't been created yet, while key_def_decode_parts()
tries to look up the collation by id. As a result, we can't enable
collations for vinyl indexes.

To fix this, let's rework the decoding procedure so that it works with
struct key_part_def instead of key_part.  The only difference between
the two structures is that the former references the collation by id
while the latter by pointer.

Needed for #2822

Writer fiber should be stopped before re-connect to avoid
sending unwanted IPROTO_OK replication acknowledges.

Fixes #2726