The first send should happen sooner, than default feedback interval, to
catch not so long-living instances. This replaces the commit we had with
sending feedback right from initial box.cfg{} and on first event
appearance, such as creation/drop of a space or index.

The reason for this commit instead of "send feedback on server start",
is that the latter one was quite hacky and didn't work correctly without
some ugly crutches, namely, fiber.sleep(10) in feedback daemon code.

Follow-up #5750

(cherry picked from commit 843fa23e74178b5eb1519e78cff36bad88b03587)

Follow-up #5750

(cherry picked from commit 5f37ecb788b80f0e12eb6eebcacd048cbf624ff9)

This reverts commit bc15e0f0.

(cherry picked from commit 3ec624b87aeb632d2bcbece9f12484cbb3298f43)

When a transaction consists of NOPs solely, it shouldn't wait for other
synchronous transactions to finish. It might get committed right away.

Such transactions may appear when applier filters out synchronous rows
from an outdated instance, and appending such transactions to the limbo
could lead to ER_UNCOMMITTED_FOREIGN_SYNC_TXNS  error, which we tried to
avoid in the first place when replaced tx rows with NOPs.

Follow-up #5445

It may happen that a Raft leader fails to send a broadcast to the
freshly connected follower.

Here's what happens: a follower subscribes to a candidate during
on-going elections. box_process_subscribe() sends out current node's
Raft state, which's candidate. Suppose a relay from follower to
candidate is already set up. Follower immediately responds to the vote
request. This makes the candidate become leader. But candidate's relay
is not yet ready to process Raft messages, and is_leader message from
the candidate gets rejected. Once relay starts, it relays all the xlogs,
but the follower rejects all the data, because it hasn't received
is_leader notification from the candidate.

Fix this by sending the last rejected message as soon as relay starts
dispatching Raft messages.

Also, while we're at it rework relay_push_raft to use a pair of
pre-allocated raft messages instead of allocating a new one on every
raft state update.

Follow-up #5445

New function name will be `box.ctl.promote()`. It's much shorter and
closer to the function's now enriched functionality.

Old name `box.ctl.clear_synchro_queue()` remains in Lua for the sake of
backward compatibility.

Follow-up #5445
Closes #3055

@TarantoolBot document
Title: deprecate `box.ctl.clear_synchro_queue()` in favor of `box.ctl.promote()`

Replace all the mentions of `box.ctl.clear_synchro_queue()` with
`box.ctl.promote()` and add a note that `box.ctl.clear_synchro_queue()`
is a deprecated alias to `box.ctl.promote()`

The `try_wait` parameter became redundant with the inroduction of manual
elections concept. It may be determined whether the node should wait for
pending confirmations or not by looking at election mode, so remove the
parameter.

Part of #3055

This patch adds support for manual elections from
`box.ctl.clear_synchro_queue()`. When an instance is in
`election_mode='manual'`, calling `clear_synchro_queue()` will make it
start a new election round.

Follow-up #5445
Part of #3055

@TarantoolBot document
Title: describe election_mode='manual'

Manual election mode is introduced. It may be used when the user wants to
control which instance is the leader explicitly instead of relying on
Raft election algorithm.

When an instance is configured with `election_mode='manual'`, it behaves
as follows:
 1) By default, the instance acts like a voter: it is read-only and may
    vote for other instances that are candidates.
 2) Once `box.ctl.clear_synchro_queue()` is called, the instance becomes a
    candidate and starts a new election round. If the instance wins the
    elections, it remains leader, but won't participate in any new elections.

Extract raft_start_candidate and raft_stop_candidate functions from
raft_cfg_is_candidate.

These functions will be used in manual elections.

Prerequisite #3055

When an instance is configured in "manual" election mode, it behaves as
a voter for most of the time, until `box.ctl.promote()` is called.

Once `box.ctl.promote()` is called the instance will behave as a
candidate for a full election round, e.g. until the leader is known. If
the instance wins the elections, it remains in `leader` state until the
next elections. Otherwise the instance returns to `voter` state.

Follow-up #5445
Part of #3055

Start writing the actual leader term together with the PROMOTE request
and process terms in PROMOTE requests on receiver side.

Make applier only apply synchronous transactions from the instance which
has the greatest term as received in PROMOTE requests.

Closes #5445

Co-developed-by: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>

PROMOTE entry will be used to mark limbo ownership transition besides
emptying the limbo. So it has to be written every time
`box.ctl.clear_synchro_queue()` succeeds. Even when the limbo was
already empty.

Part of #5445

A successful box_clear_synchro_queue() call results in writing
CONFIRM(N) ROLLBACK(N+1) pair, where N is  the confirmed lsn.

Let's write a single PROMOTE(N) entry instead. It'll have  the same
meaning as CONFIRM + ROLLBACK and it will give followers some additional
information regarding leader state change later.

Part of #5445

iproto_key_type array is used while validating incoming requests, but it
was only half-filled. The last initialized field was 0x2b, while
IPROTO_KEY_MAX is currently 0x54.

We got away with it, since the array is only  used in xrow_header_decode(),
xrow_decode_dml() and xrow_decode_synchro(), and all the keys usually present
in these requests were present in the array. This is not true anymore,
so it's time to make array contents up to date with all the IPROTO_KEY_*
constants we have.

Part of #5445

A PROMOTE entry combines effect of CONFIRM, ROLLBACK and RAFT_TERM
entries with some additional semantics on top.

PROMOTE carries the following arguments:

1) former_leader_id - the id of previous limbo owner whose entries we
   want to confirm.
2) confirm_lsn - the lsn of the last former leader's transaction to be
   confirmed. In this sense PROMOTE(confirm_lsn) replaces
   CONFIRM(confirm_lsn) + ROLLBACK(confirm_lsn + 1).
3) replica_id - id of the instance issuing
   `box.ctl.clear_synchro_queue()`
4) term - the new term the instance issuing
   `box.ctl.clear_synchro_queue()` has just entered.

This entry will be written to WAL instead of the usual CONFIRM +
ROLLBACK pair on a successful `box.ctl.clear_synchro_queue()` call.

Note, the ususal CONFIRM and ROLLBACK occurrences (after a confirmed or
rolled back synchronous transaction) are here to stay.

Part of #5445

Introduce two new flags to xrow_header: `wait_ack` and `wait_sync`.
These flags are set for rows belonging to synchronous transactions in
addition to `is_commit`.

The new flags help to define whether the rows belong to a synchronous
transaction or not without parsing them all and checking whether any of
the rows touches a synchronous space.

This will be used in applier once it is taught to filter synchronous
transactions based on whether they are coming from a raft leader or not.

P.S. These flags will also be useful once we allow to turn any transaction
synchronous. Once this is done, the flags in row header will be the only
source of information on whether the transaction is synchronous or not.

Prerequisite #5445

@TarantoolBot document
Title: new values for IPROTO_FLAGS field

IPROTO_FLAGS bitfield is enriched with two new constant:
IPROTO_FLAG_WAIT_SYNC = 0x02
IPROTO_FLAG_WAIT_ACK = 0x04

IPROTO_FLAG_WAIT_SYNC is set for the last row of a transaction which
cannot be committed immediately: either because it is synchronous or
because it waits for other synchronous transactions to complete.
IPROTO_FLAG_WAIT_ACK is set for the last synchronous transaction row.

Refactor wal_assign_lsn() to accept a journal entry instead of a pair of
pointers to the first and last entry rows.

Journal entry will carry additional meta information for the last row
soon, which will be needed in wal_assign_lsn().

Prerequisite #5445

To trigger release packages creation on tagged commits need to check
GITHUB_REF environment variable if it starts with 'refs/tags/' prefix.

This patch introduces two scripts to ease crash artefacts collecting and
loading for postmortem analysis:

* tarabrt.sh - the tool collecting a tarball with the crash artefacts
  the right way: the coredump with the binary, all loaded shared libs,
  Tarantool version (this is a separate exercise to get it from the
  binary built with -O2). Besides, the tarball has a unified layout, so
  it can be easily processed with the second script:
  - /coredump - core dump file on the root level
  - /binary - tarantool executable on the root level
  - /version - plain text file on the root level with
    `tarantool --version` output
  - /checklist - plain text file on the root level with the list of the
    collected entities
  - /etc/os-release - the plain text file containing operating system
    identification data
  - all shared libraries used by the crashed instance - their layout
    respects the one on the host machine, so they can be easily loaded
    with the following gdb command: set sysroot $(realpath .)

  The script can be easily used either manually or via
  kernel.core_pattern variable.

* gdb.sh - the auxiliary script originally written by @Totktonada, but
  needed to be adjusted to the crash artefacts layout every time. Since
  there is a unified layout, the original script is enhanced a bit to
  automatically load the coredump via gdb the right way.

Closes #5569

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
Reviewed-by: Sergey Bronnikov <sergeyb@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>

LuaJIT submodule is bumped to introduce the following change:
* test: fix directory detection in lua-Harness suite

This changeset fixes the hidden bug in lua-Harness test suite that was
revealed by applying 9610c741 ('hotfix:
update libcurl submodule to 7.76.0'). This was 314-th patch in 2.8.0
release, so RPM-related tools confuse the testing machinery using the
patch revision in the building tree names[1].

[1]: https://github.com/tarantool/tarantool/runs/2361010932#step:5:10032

Follows up #5844

It was accidentally reverted by 660686e3.

Our coverity (scan.coverity.com) reports about dead code (CWE-561)
in cases where variable of type `struct errinj *` is compared with
NULL at if condition. Dead code appears due to function-like macro
`errinj()` always returns NULL at non-debug version, so execution
never goes into if block.

Added macroses ERROR_INJECT_INT and ERROR_INJECT_DOUBLE which solves
this problem like it does ERROR_INJECT macro with boolean errinj type.

Usage you can see on example of ERRINJ_STDIN_ISATTY fix in this commit.

Follows up #5040

Follow-ip of #5628

After implementation of point hole trackers only one problem has
left. When a transaction reads a value from a TREE index by key
that key may be partial and/or search type may be GE, GT etc. In
this case point hole hash table doesn't provide track of writes
into some key interval.

Implement gap trackers for those purposes. The main idea is to
store those trackers in a story of a closest tuple to the right of
the lookup (aka successor) or directly in index if there no
successor (for example if the space in empty).

Closes #5628

Reorder some code, rename a bit and and unify branches.

Part of #5628

ER_TUPLE_FOUND error message depends on the previous tests, so we can
just check error code in these tests to avoid it.

In previous version there was inconsistent/ behaviour for update
operations to nested arrays. When user try to update non existent
field of nested array along with previous update existent field,
it's works, otherwise no. For example we create tuple and two
update operations:
`t = box.tuple.new({1, 2, {11, 22}})`
`op1 = {'=', '[3][1]', 11}`
`op2 = {'=', '[3][4]', 44}`
Then in case we apply operations separately `t:update({op1})` and
then `t:update({op2})`, second operation fails but is case we apply
them together t:update({op1, op2}) they both complete successfully.

Follow up #3378

Add ability to set box.cfg options via environment variables. These
variables should have name `TT_<OPTION>`. When Tarantool instance is
started under tarantoolctl utility, environment variables have higher
priority than tarantoolctl configuration file.

Closes #5602

Co-authored-by: Leonid Vasiliev <lvasiliev@tarantool.org>
Co-authored-by: Alexander Turenko <alexander.turenko@tarantool.org>

@TarantoolBot document
Title: Set box.cfg options via environment variables

Now, it is possible to set box.cfg options via environment variables.
The name of variable should correspond the following pattern:
`TT_<NAME>`, where `<NAME>` is uppercase box.cfg option name. For
example: `TT_LISTEN`, `TT_READAHEAD`.

Array values are separated by comma. Example:

```sh
export TT_REPLICATION=localhost:3301,localhost:3302
```

An empty variable is the same as unset one.

This needed for fast type check when fetching
options from environment variable.

Part-of #5602

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>

This patch introduces mem_get_agg(). This function is used to receive
address of memory allocated for accumulation structure of the aggregate
function.

Closes #5818

This patch introduces mem_len(). This function is used to receive
length of string or binary value of MEM. If MEM is not of STRING or
VARBINARy type this function returns -1.

Part of #5818

This patch introduces mem_get_bin(). This function is used to receive
binary value from MEM. If value of MEM is not binary value, it is
converted to binary value if possible. MEM is not changed.

Part of #5818

This patch introduces mem_get_str0() and mem_as_str0(). Function
mem_get_str0() is used to receive NULL-terminated string from MEM. If
value of MEM is not NULL-terminated string, it is converted to
NULL-terminated string if possible. MEM is not changed. Function
mem_as_str0() is also used to receive NULL-terminated string from MEM,
however if MEM does not contain NULL-terminated string it converts MEM
to MEM that contains NULL-terminated string and returns its value.

Part of #5818

This patch introduces mem_get_bool(). This function is used to receive
boolean value from MEM. If value of MEM is not boolean, it is
converted to boolean if possible. MEM is not changed.

Part of #5818

This patch introduces mem_get_double(). This function is used to receive
double value from MEM. If value of MEM is not double, it is converted to
double if possible. MEM is not changed.

Part of #5818

This patch introduces mem_get_uint() function. This function is used to
receive unsigned value from MEM. If value of MEM is not unsigned, it is
converted to unsigned if possible. MEM is not changed.

Part of #5818

This patch introduces mem_get_int() function. This function is used to
receive integer value from MEM. If value of MEM is not integer, it is
converted to integer if possible. MEM is not changed.

Part of #5818