Future module trigger will allow user to call triggers from Lua. We have
function adapter to call an abstract function from any language, but
it's convenient to call Lua functions directly when they are called from
Lua, so let's add a method that allows to get underlying Lua function (or
another callable object).

NO_CHANGELOG=internal
NO_DOC=internal

The patch introduces new event subsystem. This subsystem is designed to
store user-defined triggers and has nothing in common with core triggers.

Each trigger has its own name and is represented by func_adapter.
Triggers are stored in events - named wrappers over rlist. Event objects
are opaque, hence rlist field should not be used directly - event
provides event_find_trigger, event_reset_triggers methods and
event_trigger_iterator. Iterator provides stable iteration and all the
non-deleted triggers will surely be traversed.

On way to the goal this patch also fixes include list in func_adapter.h.

Part of #8656

NO_CHANGELOG=internal
NO_DOC=internal

part_count was checked in index_def_check(), which was called too late.
Before that check:
1. `malloc(sizeof(*part_def) * part_count)` can fail for huge part_count;
2. key_def_new() can crash for zero part_count because of out of bound
   access in:

NO_WRAP
   - #1 key_def_contains_sequential_parts (def=0x5555561a2ef0) at src/box/tuple_extract_key.cc:26
   - #2 key_def_set_extract_func (key_def=0x5555561a2ef0) at src/box/tuple_extract_key.cc:442
   - #3 key_def_set_func (def=0x5555561a2ef0) at src/box/key_def.c:162
   - #4 key_def_new (parts=0x7fffc4001350, part_count=0, for_func_index=false) at src/box/key_def.c:320
NO_WRAP

Closes #8688

NO_DOC=bugfix

box.ctl.demote() used not to do anything with election_mode='off'
if the synchro queue didn't belong to the caller in the same term
as the election state.

The reason could be that if the synchro queue term is "outdated",
there is no guarantee that some other instance doesn't own it in
the latest term right now.

The "problem" is that this could be workarounded easily by just
calling promote + demote together.

There isn't much sense in fixing it for the off-mode because the
only reasons off-mode exists are 1) for people who don't use
synchro at all, 2) who did use it and want to stop. Hence they
need demote just to disown the queue.

The patch "legalizes" the mentioned workaround by allowing to
perform demote in off-mode even if the synchro queue term is old.

Closes #6860

NO_DOC=bugfix

Module API documentation is described in Doxygen comments in C/C++ files
in src/ directory. No sense to run this job for other changes. The patch
changes paths in workflow accordingly.

NO_CHANGELOG=ci
NO_DOC=ci
NO_TEST=ci

Fuzzing is a heavyweight job, we can reduce a set of paths used for
triggering this job and therefore reduce an overall time of testing in
some cases.

The patch replaces `.github/workflows/**` to
`.github/workflows/fuzzing.yml` because workflows are independent and
changes in other workflows does not affect fuzzing at all and patch adds
Lua files (`**.lua`) to ignores because fuzzing focused on C/C++ code.

NO_CHANGELOG=ci
NO_DOC=ci
NO_TEST=ci

The function update_view_references is called when an SQL view
is created or dropped. The goal of this function is to modify
(increment or decrement) view_ref_count member of spaces that
the view references.

There were a several issues that deserves to be refactored:
* By design in case of error it left the job partially done, so
  some space references were modified while some other - not.
  Although there was no bug since special steps were made in case
  of error, this pattern is inconvenient and should be avoided.
* In case of error the failing space name was returned via special
  argument which is not flexible and even requires allocation.
* Another argument - suppress_error - has actually never
  suppressed any error because the only case when an error could
  occur is creation of a view, which used suppress_error = false.
* Fail of that function was not actually covered with tests.

So this commit:
* Makes the function to do all or nothing.
* Forces the function to set diag by itself in case of error.
* Removes suppress_error argument while adding several asserts.\
* Adds a small test that fulfills coverage.

NO_DOC=refactoring
NO_CHANGELOG=reafactoring

By design a newly created SrcList object contains one element
with NULL name. That was confusing and led to strange NULL checks
in a list that could not contain NULL names.

Fix it by clearing the list before usage.

NO_DOC=refactoring
NO_CHANGELOG=reafactoring
NO_TEST=refactoring

Since we panic on OOM now, no OOM error handling is needed now.
Fix both internals of the function and how it is used in alter.

NO_DOC=refactoring
NO_CHANGELOG=reafactoring
NO_TEST=refactoring

We have a few functions that decode MsgPack data assuming it was
previously checked with mp_check(). This means it's safe to expect
that MP_EXT contains valid data because we install a custom checker
for MP_EXT in msgpack_init. So let's replace errors with assertions,
removing the dead code.

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

The new macro is like assert, but it evaluates the checked expression
even in the release mode.

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

NO_DOC=no code changes
NO_TEST=no code changes
NO_CHANGELOG=no code changes

The test gives some initial permissions for a newly created user. Then,
it synchronizes the permissions with ones that are given in the new
configuration format. The resulting permissions should be the same as
described in the configuration (plus defaults).

The code that grants the initial permissions has a typo in one of the
permission descriptions, so it is not granted (and this error is
silently ignored). It doesn't affect the test case successfulness,
because this permission is anyway expected to be revoked by the
synchronization.

The patch fixes the initial privilege granting code and makes the test
actually verifying that the given permission is revoked.

Part of #8967

NO_DOC=It is a fix of a test.
NO_CHANGELOG=see NO_DOC

They're failing on Tarantool EE, because pap-sha256 requires to setup a
secure connection. The test doesn't do that.

The test is to be updated later. Now, just disable these test cases.

Part of #8967

NO_DOC=A testing change.
NO_CHANGELOG=see NO_DOC

The hide/show prompt console functionality sometimes breaks the
`config-luatest/credentials_applier` test. The patch disables it for
affected test cases. See a comment in the test for details.

Part of #8967

NO_DOC=It is a fix of a test.
NO_CHANGELOG=see NO_DOC

It is needed to fix a problem in the
`config-luatest/credentials_applier` test. See the next commit.

NO_DOC=It is a testing helper improvement.
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC

It was forgotten in commit 6712ab9a ("config: change default paths
to var/<...>"). Overlooked, because the test case is to be run only on
Tarantool EE.

Part of #8862

NO_DOC=It is a fix of a testing problem.
NO_CHANGELOG=see NO_DOC

The instance config schema was changed in commit 4bb1eb0e ("config:
remove hashes from credentials.password"), but an example of a config
for etcd was not updated.

The example is tested on Tarantool EE, so we should update it to fix the
testing failure.

Part of #8967

NO_DOC=It is a fix of the testing problem.
NO_CHANGELOG=see NO_DOC
NO_TEST=It is a fix of a test in fact.

Follow-up #9007

NO_DOC=Will be described when full support for vshard is introduced.
NO_CHANGELOG=Addition of an example.

This update pulls the following commits:

* Add mp_check_on_error callback
* Make test output TAP compatible

It also drops the msgpack test result file because the test was switched
to the TAP compatible format.

Needed for #7968

NO_DOC=internal
NO_CHANGELOG=internal

This patch introduces initial support for the vshard configuration.
There is still a lot to be done in both vshard and the config to be able
to run vshard naturally. Key support restrictions introduced in the
patch:
1) at the moment there are only two roles: storage and router;
2) the entire config is considered a configuration for one sharded
system;
3) the rebalancer is currently disabled;
4) The router can automatically find all masters, but once all masters
are found, any changes to the masters will be ignored until
vshard.router.cfg() is called manually.

Closes #9007

NO_DOC=Will be described when full support for vshard is introduced.

This patch introduces all sharding parameters except "weight".

Part of #9007

NO_DOC=Will be described when full support for vshard is introduced.

This patch moves the code that compiles iproto.advertise.peer to
instance_config. This will allow us to use this function for
iproto.advertise.sharding.

Part of #9007

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

It is convenient for development environments, when the configuration
file and the application sources reside in the same directory.

The same logic was recently implemented for the main script, see #8182.
The same problems appears in context of startup from a configuration
file, so it seems meaningful to adjust module search paths in this case
too.

Part of #8862

NO_DOC=This change is too minor to describe in the documentation issue
       https://github.com/tarantool/doc/issues/3544. I'll work with the
       documentation team regarding details of startup/reload flow and
       we'll determine what should go to the user documentation and what
       shouldn't.

The new default directory layout is the following.

```
+ var/
  + lib/
    + instance-001/
      - *.xlog
      - *.snap
      - *.vylog
  + log/
    + instance-001/
      - tarantool.log
  + run/
    + instance-001/
      - tarantool.control
      - tarantool.pid
```

Our guess is that it should be convenient for development environments,
when the application consists of several instances. The idea is borrowed
from the `cartridge-cli` and `tt` tools.

We plan to synchronize these defaults with the `tt` tool, to simplify
cases, when pure tarantool (without `tt`) should be run in the
directories layout created by `tt`. It should simplify debugging using
`gdb`, `strace` and other tools.

Also, it should reduce possible confusion for users of `cartridge-cli`
and `tt`.

Part of #8862

NO_DOC=https://github.com/tarantool/doc/issues/3544 already points to
       the actual instance config schema

The current working directory of a tarantool process is changed during
startup to `process.work_dir`.

The mkdir applier works before and after this point, so it should take
into account both situations.

Before first box.cfg() call (in the box_cfg applier) it should prepend
directories with `process.work_dir`. However, it shouldn't do that after
the current wordking directory change.

Part of #8862

NO_DOC=It is bugfix.

The `process.work_dir` option can be set in the configuration. All the
other directories/files has the before-box-cfg creation logic and it
seems meaningful to support it for `process.work_dir` too.

Part of #8862

NO_DOC=This change is too minor to describe in the documentation issue
       https://github.com/tarantool/doc/issues/3544. I'll work with the
       documentation team regarding details of startup/reload flow and
       we'll determine what should go to the user documentation and what
       shouldn't.

For example, if we want the logs to be in a separate `var/log`
directory, it is convenient to just configure it as `var/run/{{
instance_name }}.log` and let tarantool create the parent directory.

Part of #8862

NO_DOC=This change is too minor to describe in the documentation issue
       https://github.com/tarantool/doc/issues/3544. I'll work with the
       documentation team regarding details of startup/reload flow and
       we'll determine what should go to the user documentation and what
       shouldn't.

For example, if we want the console socket to be in a separate `var/run`
directory, it is convenient to just configure it as `var/run/{{
instance_name }}.control` and let tarantool create the parent directory.

Part of #8862

NO_DOC=This change is too minor to describe in the documentation issue
       https://github.com/tarantool/doc/issues/3544. I'll work with the
       documentation team regarding details of startup/reload flow and
       we'll determine what should go to the user documentation and what
       shouldn't.

Before this patch an attempt to set, say, `wal.dir` option to a
non-existent directory `foo` succeeds, while the same with `foo/bar`
directory fails.

The patch removes a race condition check, because `fio.mktree()`
performs the check on its own. See #4660 for details.

Part of #8862

NO_DOC=It is a bugfix.

We agreed that it is up to a user how to draw a line between one set of
instances that is considered as a separate cluster and another set of
instances that is assumed as a different cluster. This line is virtual
and there is no sense to impose restrictions until we add some certain
(and consistent) semantic to word 'cluster' in context of tarantool.

Part of #8862

NO_DOC=There is an existing documentation request
       https://github.com/tarantool/doc/issues/3544 and it doesn't
       describe such details. I'll work with the documentation team on
       demand on all the necessary details anyway.

Before this patch, user password could be set or updated only for
auth_type == 'chap-sha1'. Now password can be set, updated or removed
for any auth_type. Note that the password is changed only if necessary
to minimise db writes.

Part of #8967

NO_DOC=tarantool/doc#3544 links the most actual schema,
       no need to update the issue.

In the initial credentials schema, the hashes were supposed to give a
way to have passwords out of plain-text config file.
Later, it was decided to remove this feature, because this way of
authorisation is inferior to the one with auth service and tokens,
but the latter is out of scope for current config development.
This patch removes `credentials.password.{sha1,sha256}` and moves
plain password from `credentials.password.plain` to `credentials.password`.

Part of #8967

NO_DOC=tarantool/doc#3544 links the most actual schema,
       no need to update the issue.
NO_CHANGELOG=removed feature was not released yet

Before this patch, credentials applier used to just grant all privileges
and permissions with {if_not_exists = true}. It didn't allow removing a
permission, nor setting only new permissions.

Now credentials applier converts box configuration and desired config to
an intermediate representation, calculates diff for them and only after
that applies the diff.

Part of #8967

NO_DOC=yet

Sometimes it is useful to have one function to execute command,
read and compare response.
This patch introduces such function - `roundtrip()` to
interactive_tarantool helper.

NO_CHANGELOG=test helper change
NO_TEST=test helper change
NO_DOC=test helper change

test/unit/guard.cc calls stack_break_f() recursively until the stack
overflows and a signal is fired, however it relies on undefined behavior
when compares pointers to local variables. Fixed by comparing
__builtin_frame_address() instead.

One of the examples of this UB is when ASAN allocates local variables on
fake stacks, in that case the test completes without the stack overflow.

Also this patch disables ASAN for stack_break_f() to keep the array on the
fiber stack (see the corresponding comment) and marks it as volatile to
avoid optimizing it away by the compiler.

Closes tarantool/tarantool-qa#323

NO_DOC=test fix
NO_CHANGELOG=test fix

Closes #8803

@TarantoolBot document
Title: Document `lua_eval`, `lua_call`, and `sql` grant object types

In Tarantool 3.0 we introduced the new `lua_eval`, `lua_call`, and `sql`
object types for `box.schema.user.grant` to control access to code
execution over the network protocol (IPROTO).

1. Granting the 'execute' privilege on `lua_eval` permits the user to
   execute arbitrary Lua code with the `IPROTO_EVAL` request.

   Example:

   ```Lua
   box.cfg({listen = 3301})
   box.schema.user.create('alice', {password = 'secret'})
   conn = require('net.box').connect(
       box.cfg.listen, {user = 'alice', password = 'secret'})
   conn:eval('return true') -- access denied
   box.schema.user.grant('alice', 'execute', 'lua_eval')
   conn:eval('return true') -- ok
   ```

2. Granting the 'execute' privilege on `lua_call` permits the user to
   call any global (accessible via the `_G` Lua table) user-defined
   Lua function with the `IPROTO_CALL` request. It does **not** permit
   the user to call built-in Lua functions, such as `loadstring` or
   `box.session.su`. It does **not** permit the user to call functions
   registered in the `_func` system space with `box.schema.func.create`
   (access to those functions is still controlled by privileges granted
   on `function`).

   Example:

   ```Lua
   function my_func() end
   box.cfg({listen = 3301})
   box.schema.user.create('alice', {password = 'secret'})
   conn = require('net.box').connect(
       box.cfg.listen, {user = 'alice', password = 'secret'})
   conn:call('my_func') -- access denied
   box.schema.user.grant('alice', 'execute', 'lua_call')
   conn:call('my_func') -- ok
   conn:call('box.session.su', {'admin'}) -- access denied
   ```

3. Granting the 'execute' privilege on `sql` permits the user to
   execute an arbitrary SQL expression with the `IPROTO_PREPARE`
   and `IPROTO_EXECUTE` requests. Without this privilege or the
   'execute' privilege granted on `universe`, the user is **not**
   permitted to execute SQL expressions over IPROTO anymore.
   Note that before Tarantool 3.0 any user (even guest) could execute
   SQL expressions over IPROTO. It is possible to revert to the old
   behavior by toggling the `sql_priv` compat option. Please add
   a description to https://tarantool.io/compat/sql_priv

   Example:

   ```Lua
   box.cfg({listen = 3301})
   box.schema.user.create('alice', {password = 'secret'})
   conn = require('net.box').connect(
       box.cfg.listen, {user = 'alice', password = 'secret'})
   conn:execute('SELECT 1') -- access denied
   box.schema.user.grant('alice', 'execute', 'sql')
   conn:execute('SELECT 1') -- ok
   ```

Granting the execute privilege on the 'lua_eval' object enables
evaluaing any Lua expression via IPROTO_EVAL.

Granting the execute privilege on the 'lua_call' object enables calling
any global Lua function via IPROTO_CALL except:
 - Functions from the _func system space (see box.schema.func.create).
   Access to them is still governed only by the 'function' object type.
 - Built-in functions. We assume that all functions that were added to
   _G before loading user modules are built-in.

Note, after this change access_check_universe_object becoms unused so
it's removed (merged with access_check_universe).

Part of #8803

NO_DOC=later

We are planning to add access checks for EXECUTE and PREPARE requests.
(Currently, everyone, even guest, may execute these requests.)
Checking access in tx_process_sql(), which is defined in IPROTO code,
would violate encapsulation and look inconsistent with other request
handlers. Let's move the code that actually processes an SQL request
to the new function box_process_sql() taking sql_request and returning
the result in a port object.

To unify handling of all SQL requests in box_process_sql(), we add a new
format for port_sql - UNPREPARE. The format works only for dumping port
content to MsgPack buffer - it encodes an empty map then. This way, we
don't need to return the is_unprepare flag from box_process_sql().

Needed for #8803

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

SC_ENTITY_FOO is used instead of SC_FOO when a privilege is granted to
an entire object class, not an individual object (object id is set to ''
in the _priv system space). Introduction of this new concept made the
access checking code rather confusing, especially the part converting
entity types to object types and back, and complicated addition of new
schema object types.

Actually, there's no point in maintaining separate schema object types
for entities. Instead, we can simply add a flag to the priv_def struct
saying that the object id stored in the struct is meaningless and the
privilege should be applied to an entire object class. This simplifies
the code quite a bit and makes introduction of new schema object types
must easier.

Needed for #8803

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring