Fixed Mojave Mac build with setting MACOSX_DEPLOYMENT_TARGET environment
variable for LuaJIT's Makefile. This variable specifies the minimum
version of OS X on which the target binaries are to be deployed.

The reason why we need to set MACOSX_DEPLOYMENT_TARGET to at least 10.6
is that 10.4 SDK (which is set by default in LuaJIT's Makefile) is not
longer included in Mac OS X Mojave 10.14.

See also https://github.com/LuaJIT/LuaJIT/issues/484

We already set -Wl,-macosx_version_min,10.6 (-macosx_version_min and
MACOSX_DEPLOYMENT_TARGET are synonymous), but it affects only a linker.
We possibly should remove -macosx_version_min, because it superseded by
MACOSX_DEPLOYMENT_TARGET, but it should be done with verification that
the original problem really fixed by the new way to set a deployment
target. This is not part of this patch.

Removed virtualenv usage in CI for OS X (so pip just installs packages
into a system), because OS X Mojave 10.14 does not offer virtualenv by
default.

Fixed #3797

The patch fixes the following test failure:

 | --- vinyl/deferred_delete.result        Fri Mar 15 18:17:05 2019
 | +++ vinyl/deferred_delete.reject        Fri Mar 15 18:18:18 2019
 | @@ -577,7 +577,7 @@
 |  ...
 |  sk:stat().rows -- ditto
 |  ---
 | -- 5
 | +- 25
 |  ...
 |  s:drop()
 |  ---

The failure was introduced by commit 6dd0d2fb ("vinyl: do not apply
run_count_per_level to the last level"). Due to the commit compaction of
the secondary index may happen before compaction of the primary index,
in which case deferred DELETE statements won't make it to the secondary
index in time against the test expectation. Fix this by making the first
run big enough to prevent major compaction from kicking in.

Follow-up #3657
Closes #4047

According to ANSI[1] specification, LIKE arguments must be of
string-like type (VARCHAR, CHAR, TEXT etc). If one of arguments is NULL,
then the result of LIKE function is NULL as well. This patch makes LIKE
follow these rules.

ANSI 2013 Part 2: Foundation; Chapter 8.5 <like predicate>

Closes #3954

We don't rely on this debug facility anymore, so let's remove it.

We are going to always throw an error if value of BLOB type gets to LIKE
arguments, so code under is macro is not needed anymore.

Part of #3954

The watermark is updated every second anyway, however not updating it
when the limit is reset results in vinyl/quota test failure:

 | --- vinyl/quota.result  Thu Mar 14 16:03:54 2019
 | +++ vinyl/quota.reject  Fri Mar 15 16:32:44 2019
 | @@ -146,7 +146,7 @@
 |  for i = 1, count do s:replace{i, pad} end -- does not trigger dump
 |  ---
 |  ...
 | -box.stat.vinyl().memory.level0 > count * pad:len()
 | +box.stat.vinyl().memory.level0 > count * pad:len() or box.stat.vinyl()
 |  ---
 |  - true
 |  ...

Closes #3864

This patch reworks SQL syntax errors. After this patch, these
error will be set as Tarantool errors.

Part of #3965

Fixed GC issue.

An open iterator may disrupt the following test run, because it may
prevent dump/compaction from purging stale rows. In particular,
iterators left by vinyl/iterator result in the following test failure:

 | --- vinyl/deferred_delete.result        Mon Feb 11 19:14:01 2019
 | +++ vinyl/deferred_delete.reject        Fri Mar 15 16:21:11 2019
 | @@ -155,7 +155,7 @@
 |  ...
 |  pk:stat().rows -- 5 new REPLACEs
 |  ---
 | -- 5
 | +- 10
 |  ...
 |  i1:stat().rows -- 10 old REPLACE + 5 new REPLACEs + 10 deferred DELETEs
 |  ---

Fix this by calling the Lua garbage collector to delete all dangling
iterators in the end of vinyl/iterator test.

Closes #3862

The function evio_timeout_update() failed to update the starting time
point, which lead to timeouts happening much faster than they should if
there were consecutive calls to the function.
This lead, for example, to applier timing out while reading a several
megabyte-size row in 0.2 seconds even if replication_timeout was set to
15 seconds.

Closes #4042

Run a unit test from a var directory. It is needed to, say, allow a test
to write a log file to a gitignored directory.

The only behaviour change observed on tarantool's tests is that
unit/swim.test and unit/swim_proto.test write a log.txt file to a test
var directory ./test/xxx_unit instead of ./test.

Fixed issues:

- box-py/iproto.test.py
  1) Fixed receive_response() to wait for whole response.
  2) Clean up _cluster space.

- replication-py/cluster.test.py
  1) Clean up _cluster space.

- replication-py/multi.test.py
  1) Removed vclock checking because it fails if previous test make some
     DML and vclock was incremented. Looks like it was used for debug
     and is not part of this test case.
  2) Fixed typo in 'Synchronize' block.

The following test sequences did fail due to unexpected IDs in _cluster
space:

- [box-py/iproto.test.py, null]
- [box-py/bootstrap.test.py, null]

- [replication-py/cluster.test.py, null]
- [replication-py/multi.test.py, null]

Part of #3232

Also enabled it for luajit-tap.

Part of #3232

It had been used only in Vinyl's vy_stmt_new_surrogate_from_key, which
was deleted by the previous patches, so we can drop it as well.

There are three places where we use this expensive functions while we
could get along with a cheaper one:

 - Deferred DELETE space on_replace trigger. Here we can use simple
   vy_stmt_new_delete, because the trigger is already passed a surrogate
   DELETE statement.

 - Secondary index build on_replace trigger. Here we can extract the
   secondary key, set its type to DELETE and insert it into the index.
   We don't need all the other indexed fields.

 - Secondary index build recovery procedure. Similarly to the previous
   case, we can use extracted here rather than building a surrogate
   DELETE statement.

This heavy function isn't needed anymore, as we can now insert key
statements into the memory level.

In contrast to a primary index, which stores full tuples, secondary
indexes only store extended (secondary + primary) keys on disk. To make
them look like tuples, we fill missing fields with nulls (aka tuple
surrogate). This isn't going to work nicely with multikey indexes
though: how would you make a surrogate array from a key? We could
special-case multikey index handling, but that would look cumbersome.
So this patch removes nulls from secondary tuples restored from disk
altogether. To achieve that, it's enough to use key_format for them -
then the comparators will detect that it's actually a key, not a tuple
and use the appropriate primitive.

It's actually only needed to initialize disk streams so let's pass it
to vy_write_iterator_new_slice() instead.

By convention we have two methods in each write iterator stream
implementation (including the write iterator itself as it implements
the interface too): 'stop' and 'close'. The 'stop' method is called
in a worker thread. It reverses the effect of 'start'. We need it
unreference all tuples referenced during the iteration (we must do
it in the worker thread, where the tuples were referenced in the first
place so as not to unreference tuple formats, see vy_tuple_delete).
The 'close' method is called from the tx thread to unreference tuple
formats if necessary and release memory.

For the write iterator itself we follow this convention. However,
for individual sources, for vy_slice_stream source to be more exact,
we do not - the write iterator calls both 'stop' and 'close' from
its own 'stop method. Let's cleanup this mess and make the write
iterator follow the convention. We'll need it in the next patch.

Use the format of the given statement instead. Passing format is
a legacy from the time when we have a separate format for UPSERTs.
Nowadays it only obfuscates the code.

A Vinyl statement may be either a key or a tuple. We must use different
functions for the two kinds when working with a bloom filter. Let's
introduce helpers incorporating that logic.

Notes:
 - Currently, we never add keys to bloom filters, but after the next
   patch we will, so this patch adds tuple_bloom_builder_add_key helper.
 - According to the function protocol, tuple_bloom_builder_add may fail
   with out-of-memory, but we never checked that. Fix that while we are
   at it.

No functional changes, just move a piece of code, so as not to mix it in
the next patch.

Tuple bloom filter is an array of bloom filters, each of which reflects
lookups by all possible partial keys. To optimize the overall bloom
filter size, we need to know how many unique elements there are for each
partial key. To achieve that, we require the caller to pass the number
of key parts that have been hashed for the given tuple. Here's how it
looks in Vinyl:

        uint32_t hashed_parts = writer->last_stmt == NULL ? 0 :
                tuple_common_key_parts(stmt, writer->last_stmt,
                                       writer->key_def);
        tuple_bloom_builder_add(writer->bloom, stmt,
                                writer->key_def, hashed_parts);

Actually, there's no need in such a requirement as instead we can
calculate the hash value for the given tuple, compare it with the hash
of the tuple added last time, and add the new hash only if the two
values differ. This should be accurate enough while allowing us to get
rid of the cumbersome tuple_common_key_parts helper. Note, such a check
will only work if tuples are added in the order defined by the key
definition, but that already holds - anyway, one wouldn't be able to
use tuple_common_key_parts either if it wasn't true.

While we are at it, refresh the obsolete comment to tuple_bloom_builder.

To differentiate between key and tuple statements in comparators, we set
IPROTO_SELECT type for key statements. As a result, we can't use key
statements in the run iterator directly although secondary index runs do
store statements in key format. Instead we create surrogate tuples
filling missing fields with NULLs. This won't play nicely with multikey
indexes so we need to teach iterators to deal with statements in key
format. The first step in this direction is dropping IPROTO_SELECT in
favor of identifying key statements by format.

Currently, it's called vy_stmt_new_select, but soon a key statement will
be allowed to have any type, not just IPROTO_SELECT. So let's rename it
to vy_key_new.

Store tuple_format_vtab, max_tuple_size, and key_format there.
This will allow us to determine a statement type (key or tuple)
by checking its format against key_format.

A vinyl statement (vy_stmt struct) may represent either a tuple or a
key. We differentiate between the two kinds by statement type - we use
SELECT for keys and other types for tuples. This was done that way so
that we could pass both tuples and keys to a read iterator as a search
key. To avoid branching in comparators when the types of compared
statements are known in advance, we provide several comparators, each of
which expects certain statement types, e.g. a tuple and a key. Actually,
such a micro optimization looks like an overkill, because a typical
comparator is called by function pointer and has a lot of comparisons
in the code, see tuple_compare_slowpath for instance. Eliminating one
branch will hardly make the code perform better. At the same time, it
makes the code more difficult to write. Besides, once we remove nils
from statements read from disk (aka surrogate tuples), which will
ease implementation of multikey indexes, the number of places where
types of compared statements are known will diminish drastically.
That said, let's remove optimized comparators and always use
vy_stmt_compare, which checks types of compared statements and calls
the appropriate comparator.

We advance replica->gc state only when an xlog file is fully recovered,
see recovery_close_log and relay_on_close_log_f. It may turn out that an
xlog file is fully recovered, but isn't closed properly by relay (i.e.
recovery_close_log isn't called), because the replica closes connection
for some reason (e.g. timeout). If this happens, the old xlog file
won't be removed when the replica reconnects, because we don't advance
replica->gc state on reconnect, so the useless xlog file won't be
removed until the next xlog file is relayed. This results in occasional
replication/gc.test.lua failures. Fix this by updating replica->gc on
reconnect with the current replica vclock.

Closes #4034

The function on_replace_trigger_rollback in the case of a replace
operation rollback was called with an incorrect argument, as a
result of which the used memory was freed.

The set_system_triggers and erase routines in upgrade.lua did not
proceed actions for _fk_constraint space.

Reworked memtx_tree class to use structure memtx_tree_data as a
tree node. This makes possible to extend it with service field
to implement tuple hints and multikey indexes in subsequent
patches.

Needed for #3961

The http library intelligently sets the headers "Accept",
"Connection", "Keep-Alive".
However, when the user explicitly specified them in the header
options section of the call argument, they could be written to
the HTTP request twice.
We postponed the auto headers setup before https_exececute call.
Now they are set only if they were not set by the user.

Closes #3955

When we allowed using HAVING clause without GROUP BY (b40f2443), one
possible combination was forgotten to be tested:

SELECT 1 FROM te40 HAVING SUM(s1) < 0;
-- And SUM(s1) >= 0, i.e. HAVING condition is false.

In other words, resulting set contains no aggregates, but HAVING does
contain, but condition is false. In this case no byte-code related to
aggregate execution is emitted at all. Hence, query above equals to
simple SELECT 1; Unfortunately, result of such query is the same when
condition under HAVING clause is unsatisfied.  To fix this behaviour, it
is enough to indicate to byte-code generator that we should analyze
aggregates not only in ORDER BY clauses, but also in HAVING clause.

Closes #3932
Follow-up #2364

Functions such as trim(), substr() etc should return result with
collation derived from their arguments. So, lets add flag indicating
that collation of first argument must be applied to function's result to
SQL function definition. Using this flag, we can derive appropriate
collation in sql_expr_coll().

Part of #3932

Form a separate transaction with local changes in case of replication.
This is important because we should be able to replicate such changes
(e.g. made within an on_replace trigger) back. In the opposite case
local changes will be incorporated into originating transaction and
would be skipped by the originator replica.

Needed for #2798

Fixes commit 8031071e ("Lightweight vclock_create and vclock_copy").

Closes #4033

BLOB column type is represented by SCALAR field type in terms of NoSQL.
We attempted at emulating BLOB behaviour, but such efforts turn out to
be not decent enough. For this reason, we've decided to abandon these
attempts and fairly replace it with SCALAR column type.  SCALAR column
type acts in the same way as it does in NoSQL: it is aggregator-type for
INTEGER, NUMBER and STRING types. So, column declared with this type can
contain values of these three (available in SQL) types. It is worth
mentioning that CAST operator in this case does nothing.

Still, we consider BLOB values as entries encoded in msgpack with MP_BIN
format. To make this happen, values to be operated should be represented
in BLOB form x'...' (e.g. x'000000'). What is more, there are two
built-in functions returning BLOBs: randomblob() and zeroblob().  On the
other hand, columns with STRING NoSQL type don't accept BLOB values.

Closes #4019
Closes #4023

@TarantoolBot document
Title: SQL types changes
There are couple of recently introduced changes connected with SQL
types.

Firstly, we've removed support of DATE/TIME types from parser due to
confusing behaviour of these types: they were mapped to NUMBER NoSQL
type and have nothing in common with generally accepted DATE/TIME types
(like in other DBs). In addition, all built-in functions related to
these types (julianday(), date(), time(), datetime(), current_time(),
current_date() etc) are disabled until we reimplement TIME-like types as
a native NoSQL ones (see #3694 issue).

Secondly, we've removed CHAR type (i.e. alias to VARCHAR and TEXT). The
reason is that according to ANSI SQL CHAR(len) must accept only strings
featuring length exactly equal to given in type definition. Obviously,
now we don't provide such checks. Types VARCHAR and TEXT are still
legal.

For the same reason, we've removed NUMERIC and DECIMAL types, which were
aliases to NUMBER NoSQL type. REAL, FLOAT and DOUBLE are still exist as
aliases.

Finally, we've renamed BLOB column type to SCALAR. We've decided that
all our attempts to emulate BLOB behaviour using SCALAR NoSQL type don't
seem decent enough, i.e. without native NoSQL type BLOB there always
will be inconsistency, especially taking into account possible NoSQL-SQL
interactions. In SQL SCALAR type works exactly in the same way as in
NoSQL: it can store values of INTEGER, FLOAT and TEXT SQL types at the
same time. Also, with this change behaviour of CAST operator has been
slightly corrected: now cast to SCALAR doesn't affect type of value at
all. Couple of examples:

CREATE TABLE t1 (a SCALAR PRIMARY KEY);
INSERT INTO t1 VALUES ('1');
SELECT * FROM t1 WHERE a = 1;
-- []
Result is empty set since column "a" contains string literal value '1',
not integer value 1.

CAST(123 AS SCALAR); -- Returns 123 (integer)
CAST('abc' AS SCALAR); -- Returns 'abc' (string)

Note that in NoSQL values of BLOB type defined as ones decoded in
msgpack with MP_BIN format. In SQL there are still a few ways to force
this format: declaring literal in "BLOB" format (x'...') or using one of
two built-in functions (randomblob() and zeroblob()). TEXT and VARCHAR
SQL types don't accept BLOB values:

CREATE TABLE t (a TEXT PRIMARAY KEY);
INSERT INTO t VALUES (randomblob(5));
---
- error: 'Tuple field 1 type does not match one required: expected string'
...

BLOB itself is going to be reimplemented in scope of #3650.

NMERIC and DECIMAL were allowed to be specified as column types. But in
fact, they were just synonyms for FLOAT type and mapped to NUMERIC
Tarantool NoSQL type. So, we've decided to remove this type from parser
and return back when NUMERIC will be implemented as a native type.

Part of #4019

Since now no checks connected with length of string are performed, it
might be misleading to allow specifying this type. Instead, users must
rely on VARCHAR type.

Part of #4019

Currently, there is no native (in Tarantool terms) types to represent
time-like types. So, until we add implementation of those types, it
makes no sense to allow to specify those types in table definition.
Note that previously they were mapped to NUMBER type. For the same
reason all built-in functions connected with DATE/TIME are disabled as
well.

Part of #4019