Negating unsigned size_t value and then casting it to signed off_t type
is very bad idea. On 32-bit platforms size_t is unsigned 32-bit type,
whereas off_t is signed 64-bit type.

See #2460

Slices make range size estimation inaccurate. This may lead to the
coalesce test hang waiting for all ranges to be coalesced in case the
estimated sum range size turns out to be greater than the threshold
(range_size / 2). To make sure it never happens, let's make the test
more aggressive: let it not only delete 90% keys, but also strip the
rest of padding.

We don't have any intermediate log level between INFO and DEBUG.
INFO level should be used for rare events, such as becoming a
master or accepting a replica join. INFO is the default level.

We lack a log level for "hard to debug" situations, usable
by system administrators.

Introduce a new new log level for this purpose, VERBOSE,
for verbose output.

This change should not affect any existing installations.

Update module-api.c test.

Fixes gh-2467.

Follow up #2254

Since we've switched to Type=notify, forking isn't more needed.
Disable `background = true` in tarantoolctl to avoid potential
problems with fork detection by systemd.

Closes #2437

Fixes #2423

vy_mem_iterator_restore() is incorrect when the following
two conditions are both met:

a) Some key was prepared, but hasn't been committed yet
b) vy_mem_iterator is started and hasn't finished yet

Try to fix it by adding a new condition to mem_restore invariant.

See #2423

* Fix compilation warnings on abs()
* Fix problems on OS X and CentOS 6
* Disable this test with -DENABLE_GCOV=ON

Closes #2429

Remove fiber from cord->dead and cord->alive lists on fiber_destroy().

Refactoring for #2437

* Merge `struct tarantool_coro` into `struct fiber`
* Delete coro.c and coro.h files.

Refactoring for #2438

Original behavior can be enable with `./test-run -j -1`

See https://github.com/tarantool/test-run/issues/56

Follow up previous commits. No semantic changes.

Disable tuple_hash() optimization for non-sequential keys.

See #2084

* Refactor templates in tuple_compare.cc to generate optimized
  versions for various field types
* Add a function pointer in key_def to select optimized
  version at runtime

Fixes #2084

* Implement tuple_extract_key_sequential() for sequential keys
* Add a function pointer to in key_def to select optimized
  version at runtime

Closes #2048

It uses error injection which is compiled out for release builds.
Also, improve the test output by adding s:count() after each space
modification for checking if the statement was actually inserted.

* update comments, messages
* add a test for changing index id

Allow to alter any index opts which don't change key_def of
the index.

Closes #1931
Closes #2109
Closes #2149

Needed for extractiong write iterator to a separate file.
Also move stat account from the function to caller code.

Change-Id: I73af73e6a34f9d7431a3c8056030c9858226b0ad

time_t is long on all major platforms, not int.

Fixes #2443

Change-Id: I7ca029ccfe87124bdc7cdd2ee1db06404f38fe39

Simplify check_param_table() arguments in index.create() and index.alter().

Closes #2148

Change-Id: I10d8d93a12e8bbd91c36f6eefc0f0e8e07636de5

Currently, only keys from vy_log_key_mask[type] may be present in a
record of the given type. Extra keys will result in an error. In
order to rework space truncate, we will have to add a new key for
VY_LOG_CREATE_INDEX record (space_version). To be able to start from
vylog generated by an older version, we need to allow extra keys. So
this patch deletes vy_log_key_mask[] and makes vy_log_record_encode()
encode only those keys whose value is different from the default one
(similarly to request_encode()). Checking for mandatory keys is now up
to vy_recovery_process_record() (currently there's the only that needs
to be checked - VY_LOG_KEY_DEF)

vy_recovery_iterate() doesn't clean vy_log_record before proceeding to
the next log entry. As a result, a run record passed to the callback by
vy_recovery_iterate() contains extra info left from the index this run
is for: index_lsn, index_id and space_id. We use this in gc and backup
callbacks to format file name. The problem is vy_recovery_iterate() is
also used internally for log rotation. Including extra keys in records
doesn't result in writing them to the log file on rotation, because per
each record type we have a mask of keys corresponding to the record
(vy_log_key_mask). In order to allow optional keys in vylog, the
following patch will change the meaning of the mask so that it only
contains mandatory keys, while a key will be written to the log only if
its value differs from the default (similarly to request_encode). Thus,
to avoid writing keys not relevant to a record type we need to clean
vy_log_record within vy_recovery_iterate() before jumping to the next
record. So this patch weans gc and backup from exploiting this feature -
let them save index_id and space_id in the context, as we do on
replication and recovery.

Info_append_double is needed to print vinyl index.info.bloom_fpr later.

It was helpful when a vinyl index could have a custom path. Currently,
it's forbidden, so we can format index path in place.

We can format it in place when needed.

There must be a reasonable timeout on quota wait time, otherwise we risk
throttling a client forever, e.g. in case of a disk error. This patch
introduces quota timeout. The timeout is configured via vinyl_timeout
configuration option and set to 60 seconds by default.

Closes #2014

Use separate function for each kind of callback. The next patch will add
an argument and a return value to the throttle callback, so it isn't apt
anymore to use the only callback to handle all cases.

Currently, we reserve quota after allocating memory, which can result in
exceeding the memory limit, e.g. after the following script

    box.cfg{vinyl_memory = 1024 * 1024}
    s = box.schema.space.create('test', {engine = 'vinyl'})
    s:create_index('pk')
    pad = string.rep('x', 2 * box.cfg.vinyl_memory / 3)
    s:auto_increment{pad}
    s:auto_increment{pad}

is done, box.info.vinyl().memory.used reports that 1447330 bytes are
allocated. Fix this by reserving quota before allocation. A test is
added later in the series.

Vinyl dump is disabled during local recovery from WAL. This is OK,
because we shouldn't exceed the quota provided we don't replay
statements that were dumped to disk before restart. Check that.

Although upsert optimizers (both sync and background) replace the
last UPSERT with a REPLACE and do not insert new statements, they
use vy_index_insert_stmt(), which increments index->stmt_count.
As a result, index->stmt_count is incremented twice.

Closes #2421

See #2429

Force tarantool-common upgrade to support systemd notifications.

+ Add missing "s" suffix to TimeoutStartSec= option.

See #1923

Check that there are no statements between prev_stmt and stmt
in the cache on vy_cache_add() before trying to build a chain.
This workaround makes vy_cache_add() more fool-proof for cases
when vy_read_iterator skips some keys during restoration.

Between prepare and commit of a transaction it is possible
that some prepared statements are read from mem.
Prepared statement has abnomal lsn > MAX_LSN.

If version of the index is changed after return of a
prepared statement and the iterator is placed to read view,
the restart and restore on a such prepared statement could
lead to restore on LSN bigger than vlsn.

Example:

        FIBER 1                        FIBER 2
       box.begin()
 replace {1}, lsn=MAX_LSN+1
 replace {2}, lsn=MAX_LSN+1
    prepare vy_tx ...
                        ->->->      open iterator
                              read {1},lsn=MAX_LSN+1 from mem
                                     yield ...
                        <-<-<-
    commit vy_tx
 replace {1, 1},lsn=100
send iterator to read view
                        ->->->
                                 iterator read view = 100
                          index version changed - restore on last_stmt
                              last_stmt = {1},lsn=MAX_LSN+1
                              last_stmt LSN > iterator VLSN
                                 ??????????????????????

Lets return in such situations the next key.