Benchmark is implemented using Google Benchmark lib. Here's benchmark
settings:
 - values: we use structure (tuple) containing pointer to heap memory
           and size (all payload is of the same size - 32 bytes);
 - keys: unsigned char (first byte in the tuple memory);
 - hash function: FNV-1a;
 - value comparator: std::memcmp();
 - value count: 10k - 100k - 1M

Before each test we prepare vector of tuples storing truly random
values.

Here's the list of results obtained on my PC (i7-8700 12 X 4600 MHz):

Insertions: ~20-12M per second;
Find (no misses): ~58-16M* per second (find by key gives the same result);
Find (many misses): ~84-30M per second;
Iteration with dereference: ~450M per second;
Insertions after erase: ~50-17M* per second;
Find after erase: ~52-17M* per second (the same as without erase);
Delete: ~32-8M* per second.

* The first value is for 10k values in hash table; second - is for 1M.

Just to have some baseline here results for quite similar benchmark for
std::unordered_map (it is also included in source file):

Insertions: ~26-8M per second;
Find (no misses): ~44-11M per second;
Iteration with dereference: ~265-56M per second;
Find after erase: ~37-13M per second.

Part of #7338

NO_TEST=<Benchmark>
NO_DOC=<Benchmark>
NO_CHANGELOG=<Benchmark>

There are a lot of pretty things introduced in 14 standard,
so let's use it.

NO_DOC=<Build change>
NO_TEST=<Build change>
NO_CHANGELOG=<Build change>

It's useful and can be used in all performance tests, so let's move it
to a separate header.

NO_TEST=<Refactoring>
NO_DOC=<Refactoring>
NO_CHANGELOG=<Refactoring>

Before this patch struct tuple had two boolean bit fields: is_dirty and
has_uploaded_refs. It is worth mentioning that sizeof(boolean) is
implementation depended. However, in code it is assumed to be 1 byte
(there's static assertion restricting the whole struct tuple size by 10
bytes). So strictly speaking it may lead to the compilation error on
some non-conventional system. Secondly, bit fields anyway consume at
least one size of type (i.e. there's no space benefits in using two
uint8_t bit fields - they anyway occupy 1 byte in total). There are
several known pitfalls concerning bit fields:
 - Bit field's memory layout is implementation dependent;
 - sizeof() can't be applied to such members;
 - Complier may raise unexpected side effects
   (https://lwn.net/Articles/478657/).

Finally, in our code base as a rule we use explicit masks:
txn flags, vy stmt flags, sql flags, fiber flags.

So, let's replace bit fields in struct tuple with single member called
`flags` and several enum values corresponding to masks (to be more
precise - bit positions in tuple flags).

NO_DOC=<Refactoring>
NO_CHANGELOG=<Refactoring>
NO_TEST=<Refactoring>

When applier ack writer was moved to applier thread, it was overlooked
that it would start sharing replicaset.vclock between two threads.

This could lead to the following replication errors on master:

 relay//102/main:reader V> Got a corrupted row:
 relay//102/main:reader V> 00000000: 81 00 00 81 26 81 01 09 02 01

Such a row has an incorrectly-encoded vclock: `81 01 09 02 01`.
When writer fiber encoded the vclock length (`81`), there was only one
vclock component: {1: 9}, but at the moment of iterating over the
components, another WAL write was reported to TX thread, which bumped
the second vclock component {1: 9, 2: 1}.

Let's fix the race by delivering a copy of current replicaset vclock to
the applier thread.

Also add a perf test to the perf/ directory.

Closes #7089
Part-of tarantool/tarantool-qa#166

NO_DOC=internal fix
NO_TEST=hard to test

tuple_format_new has lots of arguments, all of them necessary
indeed. But a small analysss showed that almost always there are
only two kinds of usage of that function: with lots of zeros as
arguments and lots of values taken from space_def.

Make two versions of tuple_format_new:
simple_tuple_format_new, with all those zeros omitted, and
space_tuple_format_new, that takes space_def as an argument.

NO_DOC=refactoring
NO_CHANGELOG=refactoring

We should link box_test_utils to tuple perf test to
prevent this error.

Follow up #2717

NO_CHANGELOG=build fix
NO_DOC=build fix
NO_TEST=build fix

Implement ability to set compression for tuple fields. Compression type
for tuple fields is set in the space format, and can be set during space
creation or during setting of a new space format.
```lua
format = {{name = 'x', type = 'unsigned', compression = 'none'}}
space = box.schema.space.create('memtx_space', {format = format})
space:drop()
space = box.schema.space.create('memtx_space')
space:format(format)
```
For opensource build only one compression type ('none') is
supported. This type of compression means its absence, so
it doesn't affect something.

Part of #2695

NO_CHANGELOG=stubs for enterprise version
NO_DOC=stubs for enterprise version

There were two problems with resource release in performance test:
- because of manually zeroing of `box_tuple_last`, tuple_format
  structure was not deleted. `box_tuple_last` should be zeroed in
  `tuple_free` function.
- invalid loop for resource release in one of the test cases.
This patch fix both problems.

NO_CHANGELOG=test fix
NO_DOC=test fix

Use of PROJECT_ prefix gives ability to build the project as a
submodule of other projects.

This is helper to set proper tuple_format vtable depending on allocator
symbolic name.

Follow-up #5419

It is assumed to accumulate all allocation setting across all allocators
in order to unify Allocator::create() interface.

Follow-up #5419

Patch which prepare ability to select memory allocator.
Changed tuple allocation functions to templates, with
parameterized by the memory allocator type.
Part of #5419

Previously in memtx space direct memtx_tuple_new/memtx_tuple_delete
function calls were used. Also pointers to functions, used for alloc/free
memory for memtx tuples are stored in tuple_format_vtab. Replaced direct
memtx_tuple_new and memtx_tuple_delete function calls in memtx_space to
calls via pointers from vtab.
Part of #5419

Part of #5385