Closes #5465

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Part of #5442

Reviewed-by: Sergey Ostanevich <sergos@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

Closes #5736

Closes #5650

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5458

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Update the test-run submodule with updating its tarantool-python
submodule with the Response.__str__() change, which unifies behaviour
between Python 2 and Python 3. We lean on this in the
box-py/call.test.py test. See more in [1].

Updated the box-py/iproto.test.py test, because it is confused by the
new IPROTO_SQL_INFO_* constants, introduced in the tarantool-python
connector in [2].

Part of https://github.com/tarantool/test-run/issues/20
Part of #5652

[1]: https://github.com/tarantool/test-run/pull/264
[2]: https://github.com/tarantool/tarantool-python/commit/9d3573e36199ee5ebc360f9017190ada9726bb23

Closes #5169

(cherry picked from commit a661bef70d4ff2ba511c6e6ea71e95c6f50beb49)

Closes #5460

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5466

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Follows up #5457

Follows up #5455

Found that artifacts uses storage space which is limited to 0,5 GiB.
To avoid of lack of the space there decided to decrease the retention
days option for artifacts from default 90 days to 21 days (3 weeks).

OSX 13 was tested for homebrew commit criteria. But a month ago
criteria list changed and OSX 13 was removed [1]. So we don't
need it any more in our commit criteria - removing.

[1] - https://github.com/Homebrew/homebrew-core/actions/runs/465259174

Found issue:

  pkg: No packages available to install matching 'py27-yaml' have been found in the repositories
  pkg: No packages available to install matching 'py27-gevent' have been found in the repositories

Happened at .travis.mk file target:

  deps_freebsd:
          sudo pkg install -y git cmake gmake icu libiconv \
                  python27 py27-yaml py27-six py27-gevent \
                  autoconf automake libtool

It happened becasue Python 2 is end of life and all OS distributions
changed to use Python 3. Also all repositories removed its copies of
the Python 2 packages.

Due to FreeBSD 12 is testing using VBox VM image which already has
all the needed Python 2 packages, the current fix is to change the
gitlab-ci job to use instead of 'test_freebsd' target, which calls
'deps_freebsd' target with calls to install Python 2 packages, use
'test_freebsd_no_deps' target without it. We really won't need these
packages feather due to next update of these gitlab-ci jobs will be
change of make targets to use Python 3 packages instead of Python 2.

Closes tarantool/tarantool-qa#4

Found issues building on Fedora 33:

  test/unit/fiber_channel.cc: In function ‘fiber_channel_basic’:
  test/unit/fiber_channel.cc:40:2: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     40 |  ok(ptr == &dummy, "fiber_channel_get()");
        |  ^
  test/unit/fiber_channel.cc:37:8: note: ‘ptr’ was declared here
     37 |  void *ptr;
        |        ^

  test/unit/fiber_channel.cc: In function ‘fiber_channel_get’:
  test/unit/fiber_channel.cc:63:2: error: ‘ptr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     63 |  ok(ptr == &dummy, "fiber_channel_get(0)");
        |  ^
  test/unit/fiber_channel.cc:61:8: note: ‘ptr’ was declared here
     61 |  void *ptr;
        |        ^

To fix the issue set ptr to NULL during initialization.

Needed for #5502
Part of #5697

Closes #5457

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5456

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5455

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

In a commit "httpc: temporary disable redirecting test case"
(4cc6978a) a set of testcases
has been disabled while the bug #4180 is open.
Right now bug is closed so it is a time to enable testcases back.

Follows up: #4180

TL;DR httpd.py warns that port is busy when restart server. With socket
option SO_REUSEADDR it allows to restart httpd.py without problem.

Socket option SO_REUSEADDR tells the kernel that even if this port is
busy, go ahead and reuse it anyway. If it is busy, but with another
state, you will still get an address already in use error. It is useful
if your server has been shut down, and then restarted right away while
sockets are still active on its port.

Set correct encoding on opening file.

Follows up: #5538

Pass http body as byte string, define string literals correctly
and make items() iterable.

Follows up: #5538

Closes #5467

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5469

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

Closes #5468

Reviewed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>

Co-authored-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Co-authored-by: Igor Munkin <imun@tarantool.org>

GH allows to create custom templates for different kind of issues.
So two separate types of templates added: for feature requests and
for bug reports.

GH also allows to redirect users from a new issue page to external
resources. So requests with commercial support redirected to Tarantool
website and questions redirected to GH Discussions.

Old bug report template has been removed.

Closes #5642

Not all invalid characters were ignored by base64 decoder
causing data corruption and reads beyond decode table
(faults under ASAN).

Added corresponding check into base64 unit test.

Fixes: #5627

* core: remove excess assertion inside memprof
* core: fix resources leak in memory profiler
* misc: fix build with disabled memory profiler

Follows up #5442

Export libcurl's symbols only when they are provided by tarantool
itself: when the library is linked statically into the tarantool's
executable. There is no much sense to export the symbols when we link
against the library dynamically.

Regarding motivation of the change. Since 2.6.0-36-g29ec62891 ('Ensure
all curl symbols are exported') the curl_multi_poll() function is
exported from the tarantool executable. It leads to a failure in
Homebrew's build, because there we link (dynamically) with a system
libcurl. On Mac OS 10.15 it is libcurl 7.64.1, while the function
appears since libcurl 7.66.0. So a linker reports the undefined symbol:
`curl_multi_poll`.

Now the symbols are not exported at dynamic linking with libcurl, so the
linker is happy.

This commit relaxes bounds for dynamic linking, but an attempt to link
with libcurl older than 7.66.0 statically still leads to a linking
failure. The box-tap/gh-5223-curl-exports.test.lua test still fails when
tarantool is linked (dynamically) against an old libcurl.

It looks as the good compromise. When libcurl functionality is provided
by tarantool itself, *all* functions listed in the test are present
(otherwise a linker will complain). But tarantool does not enforce a
newer libcurl version, when it just *uses* this functionality and don't
provide it for modules and stored procedured. It is not tarantool's
responsibility in the case.

We possibly should skip the box-tap/gh-5223-curl-exports.test.lua test
when tarantool is built against libcurl dynamically or revisit the
described approach. I'll leave it as possible follow up activity.

Fixes #5542

Hotfix of 88b76800

Fix an obvious bug - tuple ref/unref manipulation must be done only
 when we handle the primary index. Even code comment states that.

Part of #5628

Now we have a PID 1 zombie reaping problem, when zombie processes
launched in Docker aren't collected by init, how it would be done if we
launch it on a real host.

It is fixed by adding --init option, when a container is created or
started.

Co-authored-by: Artem Starshov <artemreyt@tarantool.org>

Follows up #4983

The general purpose registers were optional earlier
lets make them optional back allowing the code to
be compiled on non x86-64 machines.

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>

Product team would prefer to have more data to
be included into a crash report.

So we add "instance" key with appropriate values
(just like regular feedback entry has). For example

| {
|   "crashdump": {
|     "version": "1",
|     "data": {
|       "uname": {
|         "sysname": "Linux",
|         "release": "5.9.14-100.fc32.x86_64",
|         "version": "#1 SMP Fri Dec 11 14:30:38 UTC 2020",
|         "machine": "x86_64"
|       },
|       "instance": {
|         "server_id": "336bfbfd-9e71-4728-91e3-ba84aec4d7ea",
|         "cluster_id": "176f3669-488f-46a5-a744-1be0b8a31029",
|         "uptime": "3"
|       },
|       "build": {
|         "version": "2.7.0-183-g02970b402",
|         "cmake_type": "Linux-x86_64-Debug"
|       },
|       "signal": {
|         "signo": 11,
|         "si_code": 0,
|         "si_addr": "0x3e800095fb9",
|         "backtrace": "#0  0x6317ab in crash_collect+bf...",
|         "timestamp": "2020-12-28 21:09:29 MSK"
|       }
|     }
|   }
| }

Closes #5668

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>

Since a space holds pointers to tuples it must increment
reference counters of its tuples and must decrement counters
of tuples that are deleted from the space.

Memtx TX manager also holds references to processing tuples
in the same way.

Before this patch there was a logic: while a tuple is dirty
it belongs to TX manager and does not belong to the space. Only
when a tuple is cleared and it is still in space it will be
referenced by space.

That logic leads to crashes in some DDL requests since they
works with indexes directly. For example deleting an index
causes dereferencing of all its tuples - even dirty.

This patch changes the logic. Now all tuples that are physically
in the primary index of the space a referenced. Once removed from
primary index - the tuple is dereferenced. TX manager references
tuples like before - every holding tuple is referenced.

Part of #5628

Part of #5628

There was a typo in collection of read set - a dirty
tuple was added instead of clean.

Closes #5559

The problem happened when a tuple story was delete by two
statements, one committed and one not committed.

Part of #5628

Previously, in small allocator, memory pools
were allocated at the request, which in the case
of a small slab_alloc_factor led to use
pools with incorrect sizes. This patch changed
small allocator behavior, now we allocate pools
on the stage of allocator creation. Also we use
special function to find appropriate pool, which
is faster, then previous version with rbtree.
This change fixes #5216.

Also moved a check, that the slab_alloc_factor is in
the range (1.0, 2.0] from small allocator to memtx_engine.
If factor is not in range change it to 1.0001 or 2.0 respectively

Closes #5216

* Fix Centos6 build failed
* Fix build error
* Remove Ubuntu 19.04 Disco
* small: implement new size class evaluation
* test: add small allocator performance test
* small: changed small allocator pool management