You can speicify how many extra bytes you need
for each tuple of this format.

Needed for #1908

* Check for missing cpuid.h header
* Fix sed magic in extra/mkexports
* Fix open_memstream implementation
* Fix CLOCK_PROCESS_CPUTIME_ID / CLOCK_THREAD_CPUTIME_ID
* Disable stupid -Wchar-subscripts warnings
* Add a workaround for "undefined __gcc_personality_v0"

Tested on NetBSD 7 and on x86_64-rumprun-netbsd.
Now you can use Tarantool on toasters.

 * Fix cross-compilation of LuaJIT
 * Fix txt2c and bin2c for cross-compilation
 * Check for invalid CMAKE_SYSTEM_PROCESSOR values

libreadline needs termcap OR curses/ncurses.

* Remove is_cleaned_up flags, check that actual resources instead
* Rename iterator_clean_up() to iterator_cleanup()
* Remove vy_read_iterator_cleanup() and vy_cache_iterator_cleanup()

lsregion_gc() removes data with ids less or EQUAL to min_id

This allows to have in one index multiple mems
with different formats, for example, after
altering space.

An index drop results in changing the space format, which means that
statements inserted into the space after and before an index drop have
different formats. When dumping an in-memory tree, we need to know the
format of its statements. Keeping track of all possible formats tuples
of an in-memory tree can have would be cumbersome. It's easier to simply
rotate in-memory trees of all ranges of the space whose index was
dropped so that each tree could only have the only format. To make it
effective, we rotate trees lazily, on first insertion into a tree after
ddl. To keep things simple, we rotate in-memory trees on each and every
ddl, i.e. each time we see sc_version change. Note, we rotate trees in
vy_commit() -> vy_tx_write() rather than in vy_prepare(). This is
because sc_version is changed after WAL write.

* add comments,
* use tx_prio for endpoint name.

Add a separate endpoint to wake up tx fibers from the wal thread.
The endpoint can be used for any purposes which do not involve
a yield. A yield is not allowed because the endpoint handler is executed
outside a fiber pool context. This is an alternative, more reliable
fix for the problem addressed by 975e92e3
and filed in gh-1892, when tx thread could deadlock if there
are too many connections or messages coming from iproto thread.

* add flags to fiber_pool.c
* rewrite the fix for cascading rollback to avoid calling
  fiber_reschedule() when it's not a cascading rollback.
* add an assert that dead fiber can not be woken up; ignore
  the case in production.

Track fiber state: sleep, ready, scheduled, running and dead. Don't
put fiber in an ready list if fiber is already scheduled for execution.

'continue' doesn't work inside ERROR_INJECT() macro, because it is
expanded in a do{}while(0) loop.

See #1610

Create ranges with one page and try to select from it.

Closes #1778

Closes #2030

See #1874

 - Fix memory leak in vy_task_compact_new() - split_key is never freed.
   We don't need to copy it there, because page->min_key is guaranteed
   to stay alive during vy_task_split_new().
 - Do not call vy_key_dup() on record's begin/end on recovery. Simply
   pass them directly to vy_range_new() - the latter will copy them
   for us.
 - Mark begin/end arguments of vy_range_new() const.

Make Travis CI green again!

* Remove duplicated code
* Add missing diag_set()
* Rename vy_copy_raw_key() to vy_key_dup()

* add tuple cache stat: number of cached tuples and quota usage
* add iterator stat: lookups/steps for every type
* fix tuple cache: add 'stop' flag to restore funcs, like in next funcs

Use index base from request for upsert operation.

Fixes #2059

* minor fixes after an incorrect rebase
* use fiber_schedule_cb for cbus wakeup callback
  and remove duplicate implementations.
* remove wal->exiting
* generalize wal shutdown mechanism

Extract fiber pool from cbus endpoint. cbus_join will init endpoint and
register callback. Callback will be called when new messages delivered
to empty endpoint. Fiber pool contains endpoint struct and internally
joins to cbus, handles callbacks and process messages.
Remove fiber pool from iproto and wal threads.

Jenkinsfile is a script, akin to .travis.yml that contains
instructions how to build code in the repo. I'm experimenting
to see if we can implement a similar workflow to what we have
on travis.ci

Jenkinsfile is a script, akin to .travis.yml that contains
instructions how to build code in the repo. I'm experimenting
to see if we can implement a similar workflow to what we have
on travis.ci