box.cfg() updates only those options that have actually changed.
However, for replication it is not always true: box.cfg{replication = x}
and box.cfg{replication = {x}} are treated differently, and as
the result - replication is restarted. The patch fixes such behaviour.

Closes #3711

In box_cfg() we have a call to gc_set_wal_watcher(), which creates pipes
between 'wal' and 'tx' under the hood using cbus_pair().
While pipes are being created, the fiber calling gc_set_wal_watcher()
will process all the messages coming to 'tx' thread from iproto. This is
wrong, since we have a separate fiber pool to handle iproto messages,
and background fibers shouldn't participate in these messages
processing. For example, this causes occasional credential corruption in
the fiber executing box_cfg().

Since tx fiber pool is already created at the time gc_set_wal_watcher()
is called, we may forbid message processing for the fiber which calls
the function, one of the tx fiber pool fibers will wake us up when the
pipes are created.

Closes #3779

Closes #3790

FreeBSD 10.4 has no libdl.so.

Fixes #3750.

FreeBSD does not include headers recursively, so we need to include it
explicitly at least for using IPPROTO_UDP macro.

Thanks Po-Chuan Hsieh (@sunpoet) for the fix proposal (PR #3739).

Fixes #3677.

If field isn't defined by space format, than in case of multiple
indexes field option is_nullable was the same as it was for last
index that defines it. This is wrong as it should be 'true' only
if it is 'true' for all indexes that defines it.

Closes #3744.

Trace corresponding Lua state as well as normal C stack frames while
fiber backtracing. This might be useful for debugging purposes.

Fixes: #3538

Lua trigger invocation reuses a fiber lua state if exists instead of
creating of new one for each new invocation. This is needed for a lua
stack reconstruction during backtracing.

Relates: #3538

Each yielded fiber has a preserved coro state stored in a corresponding
variable however an executing fiber has a volatile state placed in CPU
registers (stack pointer, instruction pointer and non-volatile registers)
and corresponding context-storing variable value is invalid.
For already yielded fiber we have to use a special asm-written handler to make
a temporary switch to the preserved state and capture executing context what
is not needed for executing fiber.
After the patch for the executing fiber NULL is passed to the backtrace
function as coro context and then backtrace function could decide should
it use special context-switching handler or might just use unw_getcontext
from the unwind library.

Do not inline coro_unwcontext because the unwind handler expects
for a separate stack frame.

Starting from libcurl 7.62.0, CURL_SSL_CACERT is defined as a macro
alias to CURLE_PEER_FAILED_VERIFICATION, see

  https://github.com/curl/curl/commit/3f3b26d6feb0667714902e836af608094235fca2

This breaks compilation:

  httpc.c:337:7: error: duplicate case value 'CURLE_PEER_FAILED_VERIFICATION'
          case CURLE_PEER_FAILED_VERIFICATION:
               ^
  httpc.c:336:7: note: previous case defined here
          case CURLE_SSL_CACERT:
               ^
  curl.h:589:26: note: expanded from macro 'CURLE_SSL_CACERT'
  #define CURLE_SSL_CACERT CURLE_PEER_FAILED_VERIFICATION
                           ^

Fix this by using CURLE_SSL_CACERT only if libcurl version is less
than 7.62.0.

Note, we can't use CURL_AT_LEAST_VERSION to check libcurl version,
because it isn't available in libcurl shipped with CentOS 6.

Obviously, the version check as it is now won't work once libcurl 8.0.0
is released. Use LIBCURL_VERSION_NUM to correctly check libcurl version.

Note, we can't use CURL_AT_LEAST_VERSION to check libcurl version,
because it isn't available in libcurl shipped with CentOS 6.

Fixex commit 7e62ac79 ("Add HTTP client based on libcurl").

When space.before_replace trigger modifies the result of a remote
operation, we clear the request header so that it gets rebuilt on
commit. This is incorrect, because as a result we don't bump the
master's component of the replica's vclock, which leads to the request
being applied again when the replica reconnects. The issue manifests
itself in sporadic replication/before_replace test failures.

Fix it by updating the request header rather than clearing it so that
replica id and lsn get preserved.

Closes #3722

To be able to switch to hot_standby instance with minimal downtime, we
need to know how far is it behind the primary instance, i.e. up to what
vclock we have recovered. Previously this was impossible because
box.info.vclock always referenced replicaset.vclock, which isn't updated
during hot_standby.

Introduce a pointer to relevant vclock: either recovery vclock (during
local recovery) or replicaset.vclock (at all other times) and use it in
box.info.vclock, box.info.lsn and box.info.signature.

@locker: renamed last_row_vclock to box_vclock and constified it.

Closes #3002

In some cases luajit does not collect cdata objects which were
transformed with ffi.cast as tuple_bless does. In consequence, internal
table with gc callback overflows and then lua crashes. There might be an
internal luajit issue because it fires only for jitted code. But assigning
a gc callback before transformation fixes the problem.

Closes #3751

Back when bloom filters were introduced, neither box.info.memory() nor
box.stat.vinyl().memory didn't exist so bloom filters were accounted to
box.runtime.info().used for lack of a better place. Now, there's no
point to account them there. In fact, it's confusing, because bloom
filters are allocated with malloc(), not from the runtime arena, so
let's drop it.

If a tuple read from a run by a slice stream happens to be out of the
slice bounds, it will never be freed. Fix it.

The leak was introduced by commit c174c985 ("vinyl: implement new
simple write iterator").

This patch adds logging amount of rows received by applier during the
join stage, the same way that recovery has it.

Closes #3165

Remove function which deletes from cache, making replace more general:
it might be used for both insertions, deletions and replaces. Also, put
assert on equality of space pointer found in cache to old one into
replace routine.

Now if the WAL thread fails to preallocate disk space needed to commit
a transaction, it will delete old WAL files until it succeeds or it
deletes all files that are not needed for local recovery from the oldest
checkpoint. After it deletes a file, it notifies the garbage collector
via the WAL watcher interface. The latter then deactivates consumers
that would need deleted files.

The user doesn't see a ENOSPC error if the WAL thread successfully
allocates disk space after deleting old files. Here's what's printed
to the log when this happens:

  wal/101/main C> ran out of disk space, try to delete old WAL files
  wal/101/main I> removed /home/vlad/src/tarantool/test/var/001_replication/master/00000000000000000005.xlog
  wal/101/main I> removed /home/vlad/src/tarantool/test/var/001_replication/master/00000000000000000006.xlog
  wal/101/main I> removed /home/vlad/src/tarantool/test/var/001_replication/master/00000000000000000007.xlog
  main/105/main C> deactivated WAL consumer replica 82d0fa3f-6881-4bc5-a2c0-a0f5dcf80120 at {1: 5}
  main/105/main C> deactivated WAL consumer replica 98dce0a8-1213-4824-b31e-c7e3c4eaf437 at {1: 7}

Closes #3397

In order to implement WAL auto-deletion, we need a notification channel
through which the WAL thread could notify TX that a WAL file was deleted
so that the latter can shoot off stale replicas. We will reuse existing
wal_watcher API for this. Currently, wal_watcher invokes the registered
callback on each WAL write so using it as is would be inefficient. To
avoid that, let's allow the caller to specify events of interest when
registering a wal_watcher.

Needed for #3397

We will add another event bitmap to wal_watcher. To avoid confusion
between them, let's rename wal_watcher->events.

This should make it easier to pass some extra information along with the
event mask. For example, we will use it to pass the vclock of the oldest
stored WAL, which is needed for WAL auto-deletion.

Needed for #3397

This function introduces a new xlog method xlog_fallocate() that makes
sure that the requested amount of disk space is available at the current
write position. It does that with posix_fallocate(). The new method is
called before writing anything to WAL, see wal_fallocate(). In order not
to invoke the system call too often, wal_fallocate() allocates disk
space in big chunks (1 MB).

The reason why I'm doing this is that I want to have a single and
clearly defined point in the code to handle ENOSPC errors, where
I could delete old WALs and retry (this is what #3397 is about).

Needed for #3397

Memory allocated for vy_write_iterator::src_heap is never freed. Fix it.
The leak was introduced by commit c174c985 ("vinyl: implement new
simple write iterator").

So that we can add more flags.

This patch adds a new entry to per index statistics reported by
index.stat():

  disk.statement
    inserts
    replaces
    deletes
    upserts

It shows the number of statements of each type stored in run files.
The new statistics are persisted in index files. We will need this
information so that we can force major compaction when there are too
many DELETE statements accumulated in run files.

Needed for #3225

Local variable total_size equals total_stmt_count.bytes_compressed so we
don't really need it.

tuple_extra() allows to store arbitrary metadata inside tuples.
To use it, one should set extra_size when creating a tuple_format.
It was introduced for storing UPSERT counter or column mask inside
vinyl statements. Turned out that it wasn't really needed as UPSERT
counter can be stored on lsregion while column mask doesn't need to
be stored at all.

Actually, the whole idea of tuple_extra() is rather crooked: why
would we need it if we can inherit struct tuple instead, as we do
in case of memtx_tuple and vy_stmt? Accessing an inherited struct
is much more convenient than using tuple_extra().

So this patch gets rid of tuple_extra(). To do that, it partially
reverts the following commits:

6c0842e0 vinyl: refactor vy_stmt_alloc()
74ff46d8 vinyl: add special format for tuples with column mask
11eb7816 Add extra size to tuple_format->field_map_size

This function was only used for creating a format for tuples with column
mask in vinyl. Not needed anymore and can be removed.

Anyway, it doesn't make much sense to duplciate a tuple format, because
it can be referenced instead. Besides, once JSON indexes are introcued,
duplicating a tuple format will be really painful. One more reason to
drop it now.

Finally, these atrocities are not used anywhere and can be removed.

This patch is a preparation for removing vy_stmt_column_mask.

This patch is a preparation for removing vy_stmt_column_mask.

If a REPLACE statement was generated by an UPDATE operation that updated
a column indexed by a secondary key, we can turn it into INSERT when the
secondary index is dumped, because there can't be an older statement
with the same key other than DELETE. Currently, we use the statement
column mask to detect such REPLACEs in the write iterator, but I'm
planning to get rid of vy_stmt_column_mask so let's instead introduce
a new statement flag to mark such REPLACEs.

This patch introduces a helper function vy_perform_update() that
performs operations common for UPDATE and UPSERT, namely replaces
a tuple in a transaction write set.

An UPDATE operation is written as DELETE + REPLACE to secondary indexes.
We write those statements to the memory level even if the UPDATE doesn't
actually update columns indexed by a secondary key. We filter them out
in the write iterator when the memory level is dumped. That's what we
use vy_stmt_column_mask for.

Actually, there's no point to keep those statements until dump - we
could as well filter them out when the transaction is committed. This
would even save some memory. This wouldn't hurt read operations, because
point lookup doesn't work for secondary indexes by design and so we have
to read all sources, including disk, on every read from a secondary
index.

That said, let's move update optimization from the write iterator to
vy_tx_commit. This is a step towards removing vy_stmt_column_mask.

The behaviour change was introduced in cda3cb55: sync_is_async option
was forgotten to be updated from xdir; sync_interval was forgotten too,
but was restored in 1900c58b.

The commit fixes the performance regression around 6-14% for average RPS
on default nosqlbench workload with 30 seconds duration. The additional
information about benchmarking can be found in #3747.

Thanks to Vladimir Davydov (@locker) for the investigation of the
cda3cb55 changes.

Closes #3747

(cherry picked from commit cd9cc4c5)

During SUBSCRIBE the master sends only those rows originating from the
subscribed replica that aren't present on the replica. Such rows may
appear after a sudden power loss in case the replica doesn't issue
fdatasync() after each WAL write, which is the default behavior. This
means that a replica can write some rows to WAL, relay them to another
replica, then stop without syncing WAL file. If this happens we expect
the replica to read its own rows from other members of the cluster upon
restart. For more details see commit eae84efb ("replication: recover
missing local data from replica").

Obviously, this feature only makes sense for SUBSCRIBE. During JOIN
we must relay all rows. This is how it initially worked, but commit
adc28591 ("replication: do not delete relay on applier disconnect"),
witlessly removed the corresponding check from relay_send_row() so that
now we don't send any rows originating from the joined replica:

  @@ -595,8 +630,7 @@ relay_send_row(struct xstream *stream, struct xrow_header *packet)
           * it). In the latter case packet's LSN is less than or equal to
           * local master's LSN at the moment it received 'SUBSCRIBE' request.
           */
  -       if (relay->replica == NULL ||
  -           packet->replica_id != relay->replica->id ||
  +       if (packet->replica_id != relay->replica->id ||
              packet->lsn <= vclock_get(&relay->local_vclock_at_subscribe,
                                        packet->replica_id)) {
                  relay_send(relay, packet);

(relay->local_vclock_at_subscribe is initialized to 0 on JOIN)

This only affects the case of rebootstrap, automatic or manual, because
when a new replica joins a cluster there can't be any rows on the master
originating from it. On manual rebootstrap, i.e. when the replica files
are deleted by the user and the replica is restarted from an empty
directory with the same UUID (set via box.cfg.instance_uuid), this isn't
critical - the replica will still receive those rows it should have
received during JOIN once it subscribes. However, in case of automatic
rebootstrap this can result in broken order of xlog/snap files, because
the replica directory still contains old xlog/snap files created before
rebootstrap. The rebootstrap logic expects them to have strictly less
vclocks than new files, but if JOIN stops prematurely, this condition
may not hold, leading to a crash when the vclock of a new xlog/snap is
inserted into the corresponding xdir.

This patch fixes this issue by restoring pre eae84efb behavior: now
we create a new relay for FINAL JOIN instead of reusing the one attached
to the joined replica so that relay_send_row() can detect JOIN phase and
relay all rows in this case. It also adds a comment so that we don't
make such a mistake in future.

Apart from fixing the issue, this patch also fixes a relay leak in
relay_initial_join() in case engine_join_xc() fails, which was also
introduced by the above mentioned commit.

A note about xlog/panic_on_broken_lsn test. Now the relay status isn't
reported by box.info.replication if FINAL JOIN failed and the replica
never subscribed (this is how it worked before commit eae84efb) so
we need to tweak the test a bit to handle this.

Closes #3740

If the rate at which transactions are ready to write to the database is
greater than the dump bandwidth, memory will get depleted before the
previously scheduled dump is complete and all newer transactions will
have to wait, which may take seconds or even minutes:

  W> waited for 555 bytes of vinyl memory quota for too long: 15.750 sec

This patch set implements basic transaction throttling that is supposed
to help avoid unpredictably long stalls. Now the transaction write rate
is always capped by the observed dump bandwidth, because it doesn't make
sense to consume memory at a greater rate than it can be freed. On top
of that, when a dump begins, we estimate the amount of time it is going
to take and limit the transaction write rate accordingly.

Note, this patch doesn't take into account compaction when setting the
rate limit so compaction threads may still fail to keep up with dumps,
increasing the read amplification. It will be addressed later.

Closes #1862

vy_quota_signal() doesn't wake up a consumer if it won't be able to
proceed because of the memory limit. This is OK, but it doesn't attempt
to trigger memory dump in this case either. As a result, it may occur
that dump isn't triggered and all waiting consumers are aborted by
timeout.  E.g. this happens if memory dump releases no memory, which is
possible because memory is allocated and freed in 16 MB chunks. This
results in occasional vinyl/quota_tmeout test failures.

Fix this by moving the dump trigger right in vy_quota_may_use() so that
it's called whenever we consider a consumer for wakeup.