Introduce coll object that allows to compare strings.
Add coll_def structure and functions for its setup.
Add unit test.

Needed for #2649

Support [{field=<field_no>, type=<type>}, ...] index part format
both in box.space._index and box.schema.index.create() Lua API.

box.space_index now supports the following formats of index parts:

 1. <field_no>, <type>, <field_no>, <type>, ... -- Tarantool 1.6.0+
 2. [[<field_no>, <type>], ...] -- Tarantool 1.6.6+
 3. [{field=<field_no>, type=<type>}] -- Tarantool 1.7.6+, this patch

box.schema.upgrade() converts format #1 to #2. Format #2 is not converted
automatically to #3 yet. Let's extend box.schema.upgrade() to do that later
in order to keep upward compatibility for existing 1.7.x customers.

Lua API now supports the following formats:

1. [<field1_no>, <type1>, ,..] -- Tarantool 1.6.0+
2. [{field=<field_no>, type=<type>}] -- Tarantool 1.7.6+, this patch

In addition to format #2, [{<field_no>, type = <type>}] and
[<field_no>, <type>, may_be_added_in_the_future=xxx}] shortcut is supported.
box.schema.space.create() automatically converts format #1 to #2,
therefor all new indexes will have the new format.

Closes #2802

By some philosophic reasons it was decided to name functions
that deal with old format by name with a suffix - version of
tarantool when the format was initially introduced instead of
last version when this format was used.

Change type of 'map' argument to const char ** and return in it
the end of parsed msgpack map.

Move opt_def functions from alter.cc to opt_def.c.
Make no logical changes.

Headers duplicates are written in string separated with comma
Except special headers described in:
https://nodejs.org/api/http.html#http_message_headers

Relates to #2658

Fixes #2658

In a case of collision of field and method names, the field name have
higher priority.

Closes #1014

Aliases will allow to call tuple methods, when tuple has fields with
same names as methods. In such a case a field name has higher
priority and the tuple method with the same name becomes inaccessible
via tuple:...() API.

Needed for #1014

* Add package.search function
* Fix failing tests after patch for new loaders

Closes #2797

A patch by Alexander Turenko.

Fixes #2782

Closes #2639

It's unclear how to perform access checks in this case. Let's forbid it
explicitly until there's a user request for this feature.

- Fix the test case on macOS
- Replace os.execute("cp ...") with fio.symlink()
- Don't depend on files from other tests

Follow up #2767

- Add loader for current working directory
- Add loader for rocks searching in higher dirs like npm
- Remove rocks from `package.path` and `package.cpath`

Closes #2767

Since commit c0a30d17 ("sequence: speed up allocation of sequence
data tuple during checkpoint") sequence_data_iterator_next() does not
throw an exception, so the whole thing can be moved to sequence.c.

 - Add a new schema object class, 'sequence', which can be passed to
   box.schema.{grant,revoke} to grant access to a sequence.
 - To use a sequence (i.e. call next(), set(), or reset() on it), the
   user must either be the owner of the sequence or has a permission to
   write to it.
 - This also holds for sequences attached to spaces: the user can only
   insert a tuple to a space if he has a write access to the sequence
   attached to the space. UPDATE/DELETE do not require access to a
   sequence.
 - Automatically generated sequences are special: it can be used for
   auto increment (by passing nil to INSERT) even if the user was not
   explicitly granted access to it - it is enough to have write access
   to the space.

See #389

vy_index_validate_formats() check consistency of vy_index formats.
For example, all formats must have the same value of index_field_count
and mem_format must be equal to disk_format for the primary index.

Update disk_format for the primary key in the case when ALTER adds
a new space:format() field.

Extract struct tuple_field from field_def. Store field_def in space_def
and tuple_field in tuple_format.
It allows to do not store field names in tuple_format and do not
store binary offsets and internal flags in field definition
(specified by an user).

Make all iterators keys not const and reference them. Actually
they were not const before, because they had been casted to
(struct tuple *) explicitly by vy_tx_track().

Also it is needed for #1557, where iterators must be able to store
key, not stored in a read iterator.

Mp_compare_integer can be called from mp_compare_number. Both of
them calls mp_typeof() for their arguments. But mp_typeof() makes
lookup in a big table in msgpuck.h. Lets pass already decoded types
from mp_compare_number to mp_compare_integer.

Introduce similar functions with hint for other comparators.

Vinyl surrogate tuple can be constructed using a key and filling
not indexed fields with NULL values. But not indexed field can be
formatted using space:format. Such fields can not store NULLs and
tuple_init_field_map raises an error on it.

But vinyl actually does not use not indexed fields in surrogate
tuples so we can store NULLs in surrogate not indexed formatted
fields.

Besides, we can not use field->type != FIELD_TYPE_ANY as a flag
that a field is not indexed and is not formatted. Now ANY field
type is available for users. To check if a field can be nullified
in a surrogate tuple we must use key_def.

The same problem is actual for construction a surrogate tuple from
a normal tuple - we can not anymore use type != FIELD_TYPE_ANY to
define a field is not indexed. Moreover in such a case we also can
skip fields not used by an index and placed after the last field
used by an index.
For this optimization introduce tuple_format.index_field_count and
field_def.is_key_part.

Closes #2784

The value returned by space.auto_increment() is not guaranteed to be
monotonically growing, because this method uses max+1 for the next
generated value, which can be less than a value generated before in case
the max key is deleted. Besides, calling max() may be expensive, e.g. it
requires a disk access in case of Vinyl. So this patch implements auto
increment based on persistent sequences.

To be used for auto increment, a sequence needs to be attached to a
space. To attach an existing sequence to a space, pass 'sequence=ID' in
index options when creating or modifying the primary key. Here ID is the
name or the numeric identifier of the sequence to attach. Note,
sequences can be attached only to spaces with integer primary key.
After a sequence is attached, it will be used for auto increment when
the user passes 'nil' for the primary key value. If the user passes a
value different from 'nil', the value will be used to update the
attached sequence.

To detach a sequence from the space it was attached to, either drop the
primary key of the space or alter the primary key with 'sequence=false'.

It is not necessary to pre-create a sequence to use it for auto
increment - a sequence can be automatically generated. To generate a
sequence automatically, pass 'sequence=true' in index options.
Automatically generated sequences are named '_auto_ID', where ID is the
space id, and removed when the space is dropped or the sequence is
detached.

A sequence cannot be dropped as long as it is attached to any spaces.

Closes #389

No need to allocate a tuple buffer for every sequence value.

Currently, _sequence_data is written to the snapshot the same way as any
other memtx space - the snapshot iterator simply walks over the space
tuples and dumps them one-by-one. This is OK now, because _sequence_data
is always up-to-date. However, after the next patch, its contents may
become stale - due to technical reasons we won't update _sequence_data
if a sequence is used for auto increment in a space. To make sure we
still snapshot sequence values properly, let's introduce a special
iterator for this space that walks over the sequence cache instead of
the space contents.

Needed for #389

Currently, Index::createSnapshotIterator() returns a pointer to struct
iterator, so the iterator implementation has to deal with struct tuple,
which might not always be an option. Since the iterator is only used for
writing a snapshot, struct tuple isn't really necessary, raw msgpack
would be enough. So let's introduce snapshot_iterator which returns raw
msgpack instead of struct tuple. It is required by the next patch to
make a snapshot of _sequence_data space.

Needed for #389

Currently, read iterator adds only final statements (i.e. statements
returned to the user) to the conflict manager while intermediate DELETEs
are silently ignored. This can result to the following select()
inconsistency.

Suppose there are REPLACE{10}, DELETE{20} and REPLACE{30} (it does not
matter which source owns which statement in this example) and select({})
is called. The read iterator returns REPLACE{10} and is called again. It
scans the sources, finds DELETE{20} and silently skips to the next
statement. If its fiber yields now, and REPLACE{15} is inserted, the
read iterator will ignore it, because its curr_stmt is {20} and so it
will return {30}, i.e. the select() will return [{10}, {30}]. The same
select() called from the same transaction afterwards will, however,
return [{10}, {20}, {30}], which is inconsistent with the previous
result. This happens, because interval [{10}, {20}] was not added to the
conflict manager before the yield and so the transaction was not sent to
read view.

To avoid this, we must track not only final statements, but also
intermediate DELETEs.

There's a nuance to this patch regarding REQ case that needs to be noted
explicitly. Since source iterators can't handle REQ, in contrast to EQ,
we change vy_read_iterator->iterator_type from REQ to LE and set the
need_check_eq flag when the iterator is opened. The need_check_eq flag
makes read iterator check if the resulting statement equals the search
key before returning it to the user. This check must be performed before
vy_tx_track() is called, otherwise we might add a larger interval to the
conflict manager than necessary, resulting in unnecessary conflicts
(vinyl/tx_gap_lock test will surely catch that). So this patch moves
call to vy_tx_track() along with the need_check_eq check immediately
after vy_read_iterator_next_key() irrespective of the statement type.
The problem is vy_cache_add() still has to be called on the final
statement:

 * WAS:
   vy_cache_add(result)
   need_check_eq check; may set result to NULL
   vy_tx_track(result)

 * NOW:
   need_check_eq check; may set result to NULL
   vy_tx_track(result)
   vy_cache_add(result)

Beside the result, vy_cache_add() is passed the iterator type so it
should handle NULL properly and it sure does in case of EQ, but not in
case of REQ, because REQ was changed to LE. That is, when vy_cache_add()
is passed NULL (search end marker) in case of REQ, it thinks it saw the
leftmost statement across all keys, not the leftmost statement equal to
the search key.

I decided that the best way to overcome this is to make read iterator
handle REQ separately, just like EQ, and only replace it with LE right
before passing it down to a source iterator. This gives vy_cache_add()
enough info to handle the REQ case properly and makes the code look more
symmetrical IMO.

Suppose, a source iterator was positioned at the minimal statement
across all sources before yielding to read a disk source. Then it has
front_id equal to the front_id of the read iterator, which indicates
that the source iterator needs to be advanced on the next iteration.
However, if the statement was removed during the yield, the iterator
gets repositioned on the next statement by the restoration procedure
(see vy_read_iterator_next_key()). In this case it isn't positioned on
the minimal statement any more and hence must not be advanced on the
next iteration, but its front_id remains the same, which means it will
be advanced, possibly skipping a statement.

The situation described above can happen only in case of the tuple
cache, because other sources are append-only. Obviously, to avoid this
kind of trouble, we must reset the front_id if a source iterator is
restored to a statement that is greater than the minimal statement.

We drop a reference to itr->curr_stmt before restoring the iterator
position so we must not drop it while iterating over the cache tree.
This mistake results in funky crashes in various places, e.g. in
vy_stmt_compare(). Shame on me: I missed that during self review.

Fixes: 073c8d07 ("vinyl: rework cache iterator restore")

Initially merge sort implementation was supposed to be shared between
read and write iterators hence we got vy_merge_iterator. However, over
time such a design decision proved to be inadequate, because it turned
out that the two iterators can barely share a few lines - so different
are the tasks they solve. The write iterator has already been rewritten
without the use of the vy_merge_iterator so we can now fold the latter
in vy_read_iterator. While we are at it, spruce up some comments a bit.

So as not to confuse it with vy_merge_iterator->curr_stmt.