tarantool.debug.getsources() used to provide
lua sources only for libserver lua modules,
and was not providing sources for src/box/lua/*
modules.

Now this code works:
```lua
local tnt = require 'tarantool'
local code1 = tnt.debug.getsources('box/session')
local code1 = tnt.debug.getsources('@builtin/box/session..lua')
```

Closes #7839

NO_DOC=bugfix
NO_CHANGELOG=later

See [1] for some details on why the code for log configuration needs
some care. In short log config validity checks are spread thru many
places, on some code paths we use one checks and on other code paths
other checks. And we make repetitive validity checks many times in
runtime on single configure call.

We can also reuse code for setting default values, checking options
type and resetting values to default.

- As a side effect of refactoring one can now reset values to default thru
  `log.cfg()` so now `log.cfg()` is on par with `box.cfg` in this respect.

- This patch also drops conversion `log_level` from string to number.

  Before (shorten):

    tarantool> box.cfg{log_level='warn'}
    tarantool> box.cfg.log_level
    - info
    tarantool> log.cfg.level
    - 5

  Also:
    tarantool> log.cfg{level='info'}
    tarantool> log.cfg.level
    - 5
    tarantool> box.cfg{}
    tarantool> box.cfg.log_level
    - 5

  After patch if `log_level`/`level` is given as string than it is saved
  and returned as string too. I guess it should not affect users but looks
  more handy.

- Also fixed issue with inconsistent setting `log_nonblock` thru
  `box.cfg()` and `log.cfg()`. In former case `nil` means setting default
  depending on logger type. In the latter case `nil` meant setting
  `nonblock` to `false`.

- Also patch fixes #7447.

Closes #7447.

[1] PR for this refactoring
https://github.com/tarantool/tarantool/pull/7454

NO_DOC=refactoring/tiny API improvemnent

So one can easily check current box status.

NO_DOC=minor change

Closes #7255

getenv() return values cannot be trusted, because an attacker might set
them. For instance, we shouldn't expect, that getenv() returns a value
of some sane size.

Another problem is that getenv() returns a pointer to one of
`char **environ` members, which might change upon next setenv().

Introduce a wrapper, getenv_safe(), which returns the value only when
it fits in a buffer of a specified size, and copies the value onto the
buffer. Use this wrapper everywhere in our code.

Below's a slightly decorated output of `grep -rwn getenv ./src --include
*.c --include *.h --include *.cc --include *.cpp --include *.hpp
--exclude *.lua.c` as of 2022-10-14.
`-` marks invalid occurences (comments, for example),
`*` marks the places that are already guarded before this patch,
`X` mars the places guarded in this patch, and
`^` marks places fixed in the next commit:

NO_WRAP
```
* ./src/lib/core/coio_file.c:509:	const char *tmpdir = getenv("TMPDIR");
X ./src/lib/core/errinj.c:75: const char *env_value = getenv(inj->name);
- ./src/proc_title.c:202: * that might try to hang onto a getenv() result.)
- ./src/proc_title.c:241:	* is mandatory to flush internal libc caches on getenv/setenv
X ./src/systemd.c:54: sd_unix_path = getenv("NOTIFY_SOCKET");
* ./src/box/module_cache.c:300: const char *tmpdir = getenv("TMPDIR");
X ./src/box/sql/os_unix.c:1441: azDirs[0] = getenv("SQL_TMPDIR");
X ./src/box/sql/os_unix.c:1446: azDirs[1] = getenv("TMPDIR");
* ./src/box/lua/console.c:394: const char *envvar = getenv("TT_CONSOLE_HIDE_SHOW_PROMPT");
^ ./src/box/lua/console.lua:771: local home_dir = os.getenv('HOME')
^ ./src/box/lua/load_cfg.lua:1007: local raw_value = os.getenv(env_var_name)
X ./src/lua/init.c:575: const char *path = getenv(envname);
X ./src/lua/init.c:592: const char *home = getenv("HOME");
* ./src/find_path.c:77: snprintf(buf, sizeof(buf) - 1, "%s", getenv("_"));
```
NO_WRAP

Part-of #7797

NO_DOC=security

The _vfunc system space is the sysview for the _func system space.
However, the _vfunc format is different from the _func format. This
patch makes the _vfunc format the same as the _func format.

Closes #7822

NO_DOC=bugfix

Currently, in case of recovery from an old snapshot, Tarantool allows to
perform DDL operations on an instance with non-upgraded schema.
It leads to various unpredictable errors (because the DDL code assumes
that the schema is already upgraded). This patch forbids the following
operations unless the user has the most recent schema version:
- box.schema.space.create
- box.schema.space.drop
- box.schema.space.alter
- box.schema.index.create
- box.schema.index.drop
- box.schema.index.alter
- box.schema.sequence.create
- box.schema.sequence.drop
- box.schema.sequence.alter
- box.schema.func.create
- box.schema.func.drop

Closes #7149

NO_DOC=bugfix

By default a user might not have privileges to access the _schema space,
that will cause an error during schema_needs_upgrade(), which calls
get_version(). Fix this by using C variable dd_version_id, which is
updated in the _schema.version replace trigger.

There's a special case for upgrade() during bootstrap() - triggers are
disabled during bootstrap, that's why dd_version_id is not being updated.
Handle this by passing _initial_version=1.7.5 to the upgrade function.

Part of #7149

NO_DOC=internal
NO_CHANGELOG=internal

Currently if a non-string type is passed to luaT_key_def_set_part,
lua_tolstring returns null-pointer type_name, which is passed to
a string formatting function in diag_set.

Closes #5222

NO_DOC=bugfix

Since the function is actually an eval, by default there should
be no execute access right in public role.

Closes tarantool/security#14

NO_DOC=bugfix

Prior to this patch, it was possible to call box.execute() before box
was initialized, i.e. before calling box.cfg(). This, however, caused
box.cfg() to be called automatically, which could be problematic as some
parameters could not be changed after box.cfg() was called. After this
patch, box.execute() will only be available when the box has been
initialized.

Closes #4726

@TarantoolBot document
Title: box.execute() now available only after initialization of box

Previously, it was possible to call box.execute() before the box was
configured, in which case the box was configured automatically, which
could lead to problems with box parameters. Now box.execute() can only
be called after the box has been properly configured.

It is also forbidden to set language to SQL in a console with an
unconfigured box.

Commit 7f2c7609 ("box: add option to disable Lua FFI for read
operations") added an internal configuration option that switches all
index read operations from FFI to Lua C, which was necessary to
implement space upgrade in the EE repository. Turns out there was a
minor bug in that commit - when FFI is disabled, method usage errors
(raised when object.method is called instead of object:method) stop
working. Fix this bug and add an extensive test that checks that Lua C
and FFI implementations of index read operations are equivalent.

Fixes https://github.com/tarantool/tarantool-ee/issues/254

NO_DOC=bug fix
NO_CHANGELOG=bug manifests itself in only in EE

In most places (schema.lua for example) we use box.error() to throw
error after error return from C function. Function is supposed to set
diag and box.error() will throw error based on the diag. For
example (crypto.lua):

    local ctx = ffi.C.crypto_stream_new(algo, mode, direction)
    if ctx == nil then
        box.error()
    end

This code is nice in case C function does not forget to set a diag.

But we have a different usage idiom of box.error().

    local result = pcall(module.cfg)
    if not result and oldvals ~= nil then
        rollback_module(module, oldcfg, keys, oldvals)
        return box.error()
    end

How it can go wrong? module.cfg is not necessary a C function. If it
is a Lua function it can throw error without diag. And if diag is not
set then box.error() is NOOP. So if there is a bug in code then Lua
generates error and it will be hided in this idiom. Or code can
intentionally throw Lua error() and again it will be hided. Or diag can
be set in some other place before and error will not be hided but
instead we will receive incorrect diagnosis.

One can argue that all these cases are some kind of bugs. But in this
case it will be useful to have correct diagnosis given it does not
involve much effort.

In short let's abandon pcall/box.error usage and use pcall/error(err)
instead.

Follow-up https://github.com/tarantool/tarantool-ee/issues/200

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

Add parts required to call actual flightrec reconfiguration.

Part of https://github.com/tarantool/tarantool-ee/issues/200

NO_DOC=in EE version
NO_CHANGELOG=in EE version

The patch introduces C and Lua methods for extracting position
of tuple in index. Multikey and functional indexes are not supported.

Also this patch extends method index_create_iterator_after and adds
implementation of iterator_position for memtx tree. Options
after and fetch_pos are added to Lua select as well (both FFI and LuaC).
All the types of memtx tree indexes are supported (multikey, functional).

NO_CHANGELOG=see later commits
NO_DOC=see later commits

Closes #7633
Closes #7636

NO_DOC=bugfix
NO_CHANGELOG=bugfix for unreleased bug

The idea is borrowed from [1]: hide and save prompt, user's input and
cursor position before writing to stdout/stderr and return everything
back afterwards.

Not every stdout/stderr write is handled this way: only tarantool's
logger (when it writes to stderr) and tarantool's print() Lua function
performs the prompt hide/show actions. For example,
`io.stdout:write(<...>)` Lua call or `write(STDOUT_FILENO, <...>)` C
call may mix readline's prompt with actual output. However the logger
and print() is likely enough for the vast majority of usages.

The readline's interactive search state (usually invoked by Ctrl+R) is
not covered by this patch. Sadly, I didn't find a way to properly save
and restore readline's output in this case.

Implementation details
----------------------

Several words about the allocation strategy. On the first glance it may
look worthful to pre-allocate a buffer to store prompt and user's input
data and reallocate it on demand. However rl_set_prompt() already
performs free() plus malloc() at each call[^1], so avoid doing malloc()
on our side would not change the picture much. Moreover, this code
interacts with a human, which is on many orders of magnitude slower that
a machine and will not notice a difference. So I decided to keep the
code simpler.

[^1]: Verified on readline 8.1 sources. However it worth to note that
      rl_replace_line() keeps the buffer and performs realloc() on
      demand.

The code is organized to make say and print modules calling some
callbacks without knowledge about its origin and dependency on the
console module (or whatever else module would implement this interaction
with readline). The downside here is that console needs to know all
places to set the callbacks. OTOH, it offers explicit list of such
callbacks in one place and, at whole, keep the relevant code together.

We can redefine the print() function from every place in the code, but I
prefer to make it as explicit as possible, so added the new internal
print.lua module.

We could redefine _G.print on demand instead of setting callbacks for a
function assigned to _G.print once. The downside here is that if a user
save/capture the old _G.print value, it'll use the raw print() directly
instead of our replacement. Current implementation seems to be more
safe.

Alternatives considered
-----------------------

I guess we can clear readline's prompt and user input manually and don't
let readline know that something was changed (and restore the
prompt/user input afterwards). It would save allocations and string
copying, but likely would lean on readline internals too much and repeat
some of its functionality. I considered this option as unstable and
declined.

We can redefine behavior for all writes to stdout and stderr. There are
different ways to do so:

1. Redefine libc's write() with our own implementation, which will call
   the original libc's write()[^2]. It is defined as a weak symbol in
   libc (at least in glibc), so there is no problem to do so.
2. Use pipe(), dup() and dup2() to execute our own code at
   STDOUT_FILENO, STDERR_FILENO writes.

[^2]: There is a good article about pitfalls on this road: [2]. It is
      about LD_PRELOAD, but I guess everything is very similar with
      wrapping libc's function from an executable.

In my opinion, those options are dangerous, because they implicitly
change behavior of a lot of code, which unlikely expects something of
this kind. The second option (use pipe()) adds more user space/kernel
space context switches, more copying and also would add possible
implicit fiber yield at any `write(STD*_FILENO, <...>)` call -- unlikely
all user's code is ready for that.

Fixes #7169

[1]: https://metacpan.org/dist/AnyEvent-ReadLine-Gnu/source/Gnu.pm
[2]: https://tbrindus.ca/correct-ld-preload-hooking-libc/

NO_DOC=this patch prevents mixing of output streams on a terminal and it
       is what a user actually expects; no reason to describe how bad
       would be his/her life without it

Linearizability is a property of operations when operation performed on
any node sees all the operations performed earlier on any other node of
the cluster.

More strictly speaking, it's a property demanding that if a response
for some write request arrived earlier than some read request was made,
this read request must see the results of that (or any earlier) write
request.

This patch introduces a new transaction isolation level: 'linearizable'.
When the option is set, box.begin() is stalled until the node receives the
latest data from at least one member of the quorum. This is needed to
make sure that the node sees all the writes committed on a quorum.
The transaction is served only after the node sees the relevant data,
thus implementing linearizable semantics.

The node working on a linearizable request uses its' relays vclock sync
mechanism in order to know the fresh vclock of remote nodes.

Closes #6707

@TarantoolBot document
Title: New transaction isolation level - linearizable

There is a new transaction isolation level - linearizable.
You may call `box.begin` with `txn_isolation = 'linearizable'`, but you
can't set the default transaction isolation level to 'linearizable'.

Linearizable transactions may only perform requests to synchronous,
local or temporary memtx spaces (vinyl engine support will be added
later).

Starting a linearizable transaction requires
`box.cfg.memtx_use_mvcc_engine` to be on.

Note: starting a linearizable transaction requires that the node is the
replication **source** for at least N - Q + 1 remote replicas. Here `N` is
the count of registered nodes in the cluster and `Q` is
`replication_synchro_quorum` value (the same as
`box.info.synchro.quorum`). This is the implementation limitation. For
example, you may start linearizable transactions on any node of a
cluster in full-mesh topology, but you can't perform linearizable
transactions on anonymous replicas, because noone replicates **from**
them.

When a transcaction is linearizable it sees the latest changes performed
on the quorum of nodes in the cluster. For example, if you use
linearizable transactions to read data on a replica, such a transaction
will never read stale data: all the committed writes performed on the
master will be seen by the transaction.

Making a transaction linearizable requires some waiting until the node
receives all the committed data. In case the node can't contact enough
remote peers to determine which data is committed an error is returned.

Waiting for committed data may time out: if the data isn't received
during the timeout specified by `timeout` option of `box.begin()`, an
error is returned.

When called with `{txn_isolation = 'linearizable'}`, `box.begin()`
yields until the instance receives enough data from remote peers to be
sure that the transaction is linearizable.

Reuse check_param_table() funciton in box begin instead of some custom
parameter checking code.
As one of the side effects, unknown options are now declined by
`box.begin{}`, which becomes more and more important with new options
introduction.

In-scope-of #6707

NO_DOC=refactoring
NO_CHANGELOG=refactoring

To match space_is_temporary.

In-scope-of #6707

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

Feedback daemon is reconfiguread as many times as number of options
changed during single box.cfg call which is suboptimal. Add proper support
for modules which configure all its options in a single call.

Part of https://github.com/tarantool/tarantool-ee/issues/200

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

All merge sources (including the merger itself) share the same
`<merge source>:pairs()` implementation, which returns `gen, param,
state` triplet. `gen` is `lbox_merge_source_gen()`, `param` is `nil`,
`state` in the merge source.

The `lbox_merge_source_gen()` returns `source, tuple`. The returned
source is supposed to be the same object as a one passed to the function
(`gen(param, state)`), so the function assumes the object as alive and
don't increment source's refcounter at entering, don't decrease it at
exitting.

This logic is perfect, but there was a mistake in the implementation:
the function returns a new cdata object (which holds the same pointer to
the merge source structure) instead of the same cdata object.

The new cdata object neither increases the source's refcounter at
pushing to Lua, nor decreases it at collecting. At result, if we'll loss
the original merge source object (and the first `state` that is returned
from `:pairs()`), the source structure may be freed. The pointer in the
new cdata object will be invalid so.

A sketchy code that illustrates the problem:

```lua
gen, param, state0 = source:pairs()
assert(state0 == source)
source = nil
state1, tuple = gen(param, state0)
state0 = nil
-- assert(state1 == source) -- would fails
collectgarbage()
-- The cdata object that is referenced as `source` and as `state`
-- is collected. The GC handler is called and dropped the merge
-- source structure refcounter to zero. The structure is freed.
-- The call below will crash.
gen(param, state1)
```

In the fixed code `state1 == source`, so the GC handler is not called
prematurely: we have the merge source object alive till the end of the
iterator or till the stop of the traversal.

Fixes #7657

NO_DOC=a crash is definitely not what we want to document

strerror() is MT-Unsafe, because it uses a static buffer under the hood.
We should use strerror_r() instead, which takes a user-provided buffer.
The problem is there are two implementations of strerror_r(): XSI and
GNU. The first one returns an error code and always writes the message
to the beginning of the buffer while the second one returns a pointer to
a location within the buffer where the message starts. Let's introduce a
macro HAVE_STRERROR_R_GNU set if the GNU version is available and define
tt_strerror() which writes the message to the static buffer, like
tt_cstr() or tt_sprintf().

Note, we have to export tt_strerror(), because it is used by Lua via
FFI. We also need to make it available in the module API header, because
the say_syserror() macro uses strerror() directly. In order to avoid
adding tt_strerror() to the module API, we introduce an internal helper
function _say_strerror(), which calls tt_strerror().

NO_DOC=bug fix
NO_TEST=code is covered by existing tests

Supplemented the implementation of the `src/lib/uri` parser.
Before this fix a call `uri.parse(uri.format(uri.parse(3301)))`
returned an error of 'Incorrect URI'.
Now this call return correct `service: '3301'`.
As a result, the possibility of using host=localhost by default
for `tarantoolctl connect` has been restored now.
As well as for `console.connect`.

Fixes #7479

NO_DOC=bugfix

There's a bunch of places where func_def is used read-only. Let's mark
them with const for the sake of the code clarity.

NO_DOC=code cleanup
NO_TEST=code cleanup
NO_CHANGELOG=code cleanup

func->def is supposed to be set by func_new, but func_lua_new sets it
for func_persistent_lua_load to work. Actually, there's no need to do
this, because we can simply pass func_def to func_persistent_lua_load
instead. Let's do this - this is needed to clean up func_def handling
in func_new, which in turn is required to make a copy of a space upgrade
function for read view.

Needed for https://github.com/tarantool/tarantool-ee/issues/163

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

Currently, the helper is used only for creation of a tuple format for
Lua (needed for net.box schema). Later on, we will reuse this helper for
creating tuple formats for user read views.

Needed for https://github.com/tarantool/tarantool-ee/issues/207

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

'public' role and thus guest and any newly created user has 'write'
privilege to _collation space. It is not enough to modify _collation as
one also needs 'create' privilege to add a collation and 'drop privilege
to delete one. So it is safe. Yet looks like we don't have any purpuse
of exposing _collation now.

NO_DOC=bugfix

Simple part is a part without any extra key besides 'field' and 'type'.
Let's make a check in try_simplify_index_parts itself.

NO_TEST=refactoring
NO_DOC=refactoring
NO_CHANGELOG=refactoring

If index parts are specified using old syntax like:

	parts = {1, 'number', 2, 'string'},

then (except if parts count is 1) index options set in space format
are not taken into account. Solution is to continue after parsing 1.6.0
style parts so to use code that check format options.

Closes #7614

NO_DOC=bugfix

 - Mix-in EE Lua sources if ENABLE_READ_VIEW is set.
 - Raise an error on attempt to access box.read_view in CE.

Needed for https://github.com/tarantool/tarantool-ee/issues/139

NO_DOC=internal
NO_CHANGELOG=internal

Currently internal tarantool fibers can be cancelled from the user's app,
which can lead to critical errors.

Let's mark these fibers as a system ones in order to be sure that they
won't be cancelled from the Lua world.

Closes #7448
Closes #7473

NO_DOC=minor change

Needed for #6896

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

struct trigger is about to get a new field, and it's mandatory that this
field is specified in all initializers. Let's introduce a macro to avoid
adding every new field to all the initializers and at the same time keep
the benefits of static initialization.

Also while we're at it fix `lbox_trigger_reset` setting all trigger
fileds manually.

Part-of #4264

NO_DOC=refactoring
NO_CHANGELOG=refactoring
NO_TEST=refactoring

When multiline commands were loaded from .tarantool_history, they were
treated as a bunch of oneline commands. Now readline is configured to
write timestamps in .tarantool_history as delimiters and multiline
commands are handled correctly.

If there is already a .tarantool_history file, readline will set
timestamps automatically, nothing will be lost.

Closes #7320
NO_DOC=bugfix
NO_TEST=impossible to check readline history from lua

With current leader fencing implementation old leader doesn't resign
it's leadership before new leader may be elected. Because of this
several "leaders" might coexist in replicaset for some time.

This commit changes replication_disconnect_timeout that it is twice
as short for current raft leader (2*replication_timeout) if strict
fencing is enabled. Assuming that replication_timeout is the same for
every replica in replicaset this makes it less probable that new
leader can be elected before old one resigns it's leadership.

Old fencing behaviour can be enabled by setting fencing to soft mode.
This is useful when connection death timeouts shouldn't be affected
(e.g. different replication_timeouts are set to prioritize some
replicas as leader over the others).

Closes #7110

@TarantoolBot document
Title: Strict fencing

In `box.cfg` option `election_fencing_enabled` is deprecated in favor
of `election_fencing_mode`. `election_fencing_mode` can be set to one
of the following values:
'off' - fencing turned off (same as `election_fencing_enabled` set to
false before).
Connection death timeout is 4*replication_timeout for all nodes.

'soft' (default) - fencing turned on, but connection death timeout is
the same for leader and followers in replicaset. This is enough to
solve cluster being readonly and not being to elect a new leader in
some situations because of pre-vote.
Connection death timeout is 4*replication_timeout for all nodes.

'strict' - fencing turned on. In this mode leader tries its best to
resign leadership before new leader can be elected. This is achived
by halving death timeout on leader.
Connection death timeout is 4*replication_timeout for followers and
2*replication_timout for current leader.

It is counter-intuitive to see options of a component that is disabled
at build time. Especially, when the returned value means that the
component is enabled (while it is not so).

Before this patch (on `-DENABLE_FEEDBACK_DAEMON=OFF` build):

```yaml
tarantool> box.cfg()
tarantool> box.cfg.feedback_enabled
---
- true
...
```

After this patch (on `-DENABLE_FEEDBACK_DAEMON=OFF` build):

```yaml
tarantool> box.cfg()
tarantool> box.cfg.feedback_enabled
---
- null
...
```

NB: The following test cases in cartridge are failed with
`-DENABLE_FEEDBACK_DAEMON=OFF` (as before as well as after the patch):

* integration.feedback.test_feedback
* integration.feedback.test_rocks

Since they verify cartridge's additions for the feedback daemon, it is
expected outcome of disabling the component entirely. Ideally we should
conditionally disable those test cases, but it is out of scope here.

Follows up #3308

NO_DOC=I think it is expected behavior and unlikely it requires any
       change in the documentation
NO_TEST=a test would verify behavior of the particular build type, but
        we have no such configuration in CI, so the test would be pretty
        useless
NO_CHANGELOG=seems too minor to highlight it for users

To avoid potential buffer overflows and to make static analyzers happy.

Fixed CWE-120:
- sprintf: does not check for buffer overflows
- strcpy: does not check for buffer overflows when copying to destination
- strcat: does not check for buffer overflows when concatenating to
  destination

Closes #7534

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This change follows the previous commit regarding `luaT_newdecimal()`
and `luaT_pushdecimal()`, see explanation and details there.

Also changed the `luaL_` prefix to more appropriate `luaT_`. The `struct
tt_uuid` is our own type, the functions are specific to tarantool. So
`luaT_`.

Part of #7228

NO_DOC=refactoring, no user-visible changes
NO_TEST=refactoring, no behavior changes
NO_CHANGELOG=refactoring, no user-visible changes

Update luacheckrc to suppress all warnings from lua vars with `_` prefix.
This allows to declare a function with an expected standardized interface
without unused var warning.
Fix luacheck warnings in src/box/console.lua.

Closes #5032

NO_CHANGELOG=warning fix
NO_DOC=warning fix
NO_TEST=warning fix

The valid range for thread_id is [0, iproto_threads_count - 1].

Closes #7196

NO_DOC=bugfix