Introduced few new commands to handle breakpoints:
- `b file:NNN` to set new breakpoint;
- `bd file:NNN` to remove breakpoint;
- 'bl` to list all active breakpoints.

There is partial breakpoint notation supported when
for `b :N` or `b +N` breakpoint will be set to the
asked line in the _currently_ debugged file.

Changed `c` (continue) to stop on breakpoints, if there any active
one asssigned by user. Otherwise it still run in full speed, without
any hook check.

NO_DOC=see the later commit
NO_CHANGELOG=see the later commit

Historically luadebug.lua used `up` and `down` in
a strange order which was inherited from original
debugger.lua implementation. But that was counter
intuitive, and is confusing.

Swap their meaning to be more compatible with
that we accustomed in `gdb`/`lldb`.

NO_DOC=internal

Add a streaming data input/output object for http.client. The
input/output object can be created using the same methods and the
same options as a normal request, but with a new option
{chunked = true}.

Closes #7845

@TarantoolBot document
Title: Stream input/output interface for http.client

An uncompleted io object has only headers and cookies fields. A
completed io object has the same fields as a normal request, but
without the `body` field.

The io object interface looks like the socket object interface
and should have the same description:

```
io_object:read(chunk[, timeout])
io_object:read(delimiter[, timeout])
io_object:read({chunk = chunk, delimiter = delimiter}[, timeout])
io_object:write(data[, timeout])
```

The difference is in the method `finish`. Unlike socket:close()
it has an optional parameter `timeout`:

```
io_object:finish([timeout])
```

Be careful, the call may yield a fiber. The idea is to wait
until a HTTP connection is finished by the server-side or
force finish the connection from client-time after a timeout
value.

The default timeout value is 10 seconds for all methods.

Usage example:

```lua
local io = httpc:post(url, nil, {chunked = true})

local write_chan = fiber.channel()
fiber.new(function()
    fiber.name("write to " .. url)
    while true do
        local data = write_chan:get()
        if data == nil then
            break
        end
        io:write(data, 1)
    end
end)

local recvdata
while recvdata = io:read('\r\n', 1) do
    local decoded = json.decode(recvdata)
    if condition(decoded) then
        write_chan:put(data)
    end
    if condition(decoded) then
        io:finish(1)
    end
end
write_chan:close()
```

See also:
* https://www.tarantool.io/en/doc/latest/reference/reference_lua/socket/#lua-function.socket_object.read
* https://github.com/tarantool/tarantool/issues/7845#issuecomment-1298538412
* https://github.com/tarantool/tarantool/issues/7845#issuecomment-1298821779

We have a code that performs calculations to obtain the address from the
given index, the address is then passed to cdataV() to get cdata value from
the stack. But this doesn't work for pseudo-indexes (e.g. upvalue indexes).
This patch brings index2adr() from luajit/src/lj_api.c, which accepts all
kinds of indexes, so that the calculations are no longer needed. Also the
helper function luaL_tocpointer() is introduced.

Closes #8249

NO_DOC=bugfix

The built-in module registration process performs several assertions:

- luaT_newmodule() checks for attempts to register an already registered
  module.
- luaT_setmodule() does the same, but it allows the same value be
  'registered' several times.

Attempt to register different values as the same built-in module is
definitely an error. Once a module is registered, it may be required and
captured. If its value is changed afterwards, different parts of
tarantool's code will capture different values for the same built-in
module. It is very unlikely that such effect may be intended.

Anyway, tarantool's code doesn't do this. However, now, after
implementing the override modules feature, it is possible to influence
tarantool's initialization from a user provided code.

It means that we can't assume the situations described above as
impossible ones. A developer of an override module should receive an
error if the code of the module leads to such a situat...

Use case: an override module is designed to replace a built-in module
only when the module is required from an application, not from the
platform itself.

Now it is possible:

```lua
-- override/fio.lua
local loaders = require('internal.loaders')

if loaders.initializing then
    loaders.no_package_loaded.fio = true
    return loaders.builtin.fio
end

return {
    whoami = 'override.fio',
}
```

Follows up #7774

NO_DOC=Planned as an internal API. See the previous commit.
NO_CHANGELOG=see NO_DOC

The flag indicates, whether the loading of built-in modules is finished.
May be useful for override modules to determine, whether it is required
from inside tarantool or from application's code.

Follows up #7774

NO_DOC=It is not intended to be officially supported. I would prefer to
       document ability of loading a replacement module itself, but I
       wouldn't document how to write such a module.
NO_CHANGELOG=see NO_DOC

It eliminates a need to call `package.setsearchroot()` in the main
script to find modules in the application's directory.

Such layout is typical for cartridge based applications. It it also
used, when different versions of modules are in use in different
applications and installing the modules into the system is not an
option.

Regarding the implementation. There are two possible ways to add more
searching logic: add more entries into `package.path` and
`package.cpath` or add/wrap a loader. I'm going the second way, because
we already have a logic around .rocks and override modules implemented
as loaders. It is easier to follow.

However, I would reimplement all those loaders as paths generators for
`package.path` and `package.cpath` in a future. See also #3136.

Follows up #7774
Fixes #8182

@TarantoolBot document
Title: Default module search paths now include the main script directory

Let's assume that there is an application in the directory
/path/to/myapp with modules inside:

```
+ /path/to/myapp/
  +- .rocks/share/tarantool/
     +- foo.lua
  +- init.lua
  +- myapp/
     +- bar.lua
```

Now the following command automatically adds the path to the main script
directory to search paths for modules:

```sh
$ tarantool /path/to/app/init.lua
```

So `require('foo')` and `require('myapp.bar')` works without any
additional work.

To be used in loaders, see the next commit.

While I'm here, actualized `tarantool_lua_init()` description.

Follows up #7774
Part of #8182

NO_DOC=for internal use
NO_CHANGELOG=see NO_DOC
NO_TEST=see NO_DOC

The feedback daemon test case fails in CI after recent changes for
override modules. It is observed on GCOV (coverage) job and on macOS
jobs.

I found no direct correspondence between the changes and the feedback
daemon code/test case.

The test case runs metrics collection for 0.3 seconds with 0.01
interval. It accepts [22; 38] samples as a correct result. I got 7-22
samples on GCOV build in CI.

It means that the tested code is working, but slower. The tested code
don't run the newly added code, but the new code is run at tarantool
initialization. I think that the fails in CI are due to influence of the
changed initialization code in composition with LuaJIT's unstable
performance: some traces are collected differently, GC runs on different
points and we're here.

I changed the feedback daemon test case to accept [5; 55] samples as a
correct result.

Follows up #7774
Follows up #8192

NO_DOC=test adjustment
NO_CHANGELOG=see NO_DOC

A script for preparing tarantool for executing LuaJIT submodule test
suites has a `debug.getupvalue()` call. It is fragile and the previous
commit promises that it'll be rewritten. It is done here.

The override loader can be disabled using an internal API or by the
`TT_OVERRIDE_BUILTIN` environment variable. The latter is not used
anywhere at the moment of writing and added just in case.

Follows up #7774

NO_CHANGELOG=not planned to be a documented feature, just a tiny
             workaround for specific tests
NO_DOC=see NO_CHANGELOG

This commit finishes implementation of the logic for overriding built-in
modules. It adds the loader, which looks into a file system for
`override.foo` module when `foo` is required. It works as for
`require()` in an application/module code as well as for `require()`
called from tarantool during its initialization.

Added replacements into the treegen testing helper.

Disabled the override loader in the LuaJIT submodule test suites. It is
done using `debug.getupvalue()`, which is a fragile way. Don't worry:
the next commit reimplements this logic.

Fixes #7774

@TarantoolBot document
Title: Built-in modules overriding

Now it is possible to override a built-in module. Everything is simple
here, in fact: if `override.foo` module exists on default search paths,
it'll replace built-in `foo` module.

Sometimes it is necessary to run tarantool with particular arguments and
verify its output. `luatest.server` provides a supervisor like
interface: an instance is started, calls box.cfg() and we can
communicate with it using net.box. Another helper,
`test.interactive_tarantool`, aims to solve all the problems around
readline console and also provides ability to communicate with the
instance interactively.

However, there is nothing like 'just run tarantool with given args and
give me its output'.

This commit adds a helper for running tarantool executable with given
parameters (cwd, env, args), catch its output and parse the output as
JSON lines.

It is used in preload_test.lua and I want to use it in a future
overload_test.lua.

The code is just moved. The comment for the function is a bit expanded.

Part of #7774

NO_CHANGELOG=a testing helper is added
NO_DOC=see NO_CHANGELOG

This commit adds a generator of Lua file tree, which generates scripts
using provided templates and filenames. This approach is used in
preload_test.lua and I'm going to use it in a future overload_test.lua.

The original code from preload_test.lua remain almost same. It is
arranged to be a module and adopted for convenient use from a luatest
based test. Also, it gains ability to provide several templates for Lua
files instead of just one for all the files.

Part of #7774

NO_CHANGELOG=a testing helper is added
NO_DOC=see NO_CHANGELOG

We're going to provide an ability to override a built-in module. The
code of an override module will work in a bit unusual circumstances: a
part of tarantool's Lua runtime is initialized, but a part isn't.

However, nothing prevents us from providing the `arg` global variable at
this stage. It used to be accessible anywhere in a user defined code.
Let's keep this property by making it accessible from an override
module.

Part of #7774

NO_TEST=It will be tested as part of the override feature.
NO_CHANGELOG=It is not possible to execute any user provided code at
             this loading stage until modules overriding will be
             implemented. So this commit doesn't change any behavior
             that a user might observe before this commit.
NO_DOC=It spreads exiting runtime guarantee to a new stage, where a user
       defined code may appear. Nothing new is introduced.

It is necessary to implement overloading of a built-in module by an
external one. `require('foo')` will work this way: check for
`override.foo` module on the file system and then load built-in `foo`.

If `foo` is already assigned to `package.loaded`, the loaders will not
be called at all, so we can't check the file system.

This commit changes a built-in module registration process: the modules
are assigned into another table called `loaders.builtin`. A special
loader is added to `package.loaders` to look into this table.

Comments on the luajit-test-init.lua changes:

* The LuaJIT tests use its own tap module, so the script unloads the
  built-in tap module. However, now it is not enough to remove it from
  `package.loaded` (it'll be loaded again at next require()). It should
  also be removed from `loaders.builtin`.

  Maybe it would be better to move this external tap module to
  <...>/override/tap.lua in a future.
* `package.loaded` may miss `internal.print` and `internal.pairs` if
  they were not required. The right way to obtain the modules is to
  require() them.

Part of #7774

NO_TEST=no user visible changes
NO_CHANGELOG=see NO_TEST
NO_DOC=see NO_TEST

Further commits will change how built-in modules are registered, so a
direct assignment to `_LOADED` (`package.loaded`) is not suitable
anymore.

Precisely, it would work, but would forbid to implement an override
module.

Part of #7774

NO_TEST=no user visible changes
NO_CHANGELOG=see NO_TEST
NO_DOC=see NO_TEST

There are two flags in the LuaJIT useful for debugging and runtime
configuration purposes: `-j` and `-b`. However, if you want to
check the same Lua code from the Tarantool, you will need to make
some adjustments in the script itself, as those flags are not
present in the Tarantool's CLI.

This patch introduces those flags to the Tarantool, so debugging is
much more convenient now. Flags are working the same as they do in
the LuaJIT.

Closes #5541

NO_DOC=http://luajit.org/running.html#opt_b
NO_DOC=http://luajit.org/running.html#opt_j

Check allocation and deallocation of different sizes of
of functional index function result.

Follow-up #6786

NO_DOC=test
NO_CHANGELOG=test

Let's use xregion_alloc instead of region_alloc, because memory
allocations from fiber region shouldn't normally fail, see #3534.

Closes tarantool/security#97

NO_DOC=bug fix
NO_TEST=shouldn't normally happen
NO_CHANGELOG=see NO_TEST

This patch introduces new sql_seq_scan_default compat option. This
compat option allows to set default value for sql_seq_scan session
setting. Note that sql_seq_scan_default compat option only affects
sessions during initialization. This means that you should set
sql_seq_scan_default before running box.cfg{} or creating a new session.

Closes #8096

NO_DOC=Already exists

This patch removes unused ck_constraint.c module.

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch fixes potential read of uninitialized variable
in history_truncate_file()

Fixed in upstream:
https://git.savannah.gnu.org/cgit/readline.git/commit/?h=devel&id=b4ebdc06601fb54297435d2e286d901cba1cd6c6

Closes tarantool/security#95

NO_DOC=security
NO_TEST=security
NO_CHANGELOG=security

We plan to provide compat options information via the website. It was
requested by Kirill Yukhin instead of the wiki pages (and I don't mind
it).

NO_DOC=notified the documentation team in
       https://github.com/tarantool/doc/issues/3259
NO_TEST=it's just help messages
NO_CHANGELOG=those compat options were not released yet

n_ssl3_mac(): Fix possible divide by zero.
Fixed in openssl3:
https://github.com/openssl/openssl/commit/624efd2ba6f1dabdcdecf17c77bd206c421efdaf

Closes tarantool/security#90

NO_DOC=security
NO_TEST=security
NO_CHANGELOG=security

Sometimes we need to disable system triggers to perform a tricky change
in system spaces. Later we enable them back. But in case of error in
between we miss the enabling. With system triggers off the application
behaviour will be quite surpising. Let's fix it.

Follow-up #7718

NO_DOC=minor
NO_TEST=minor
NO_CHANGELOG=minor

We have a mechanism for detecting runtime memory leaks, see commit
19abfd2a ("misc: get rid of fiber_gc") so there's no need to test
it manually. The test is inherently flaky, because the size of runtime
memory depends on test case execution order so let's drop it.

Follow-up commit ec1a71ff ("box: introduce pagination to memtx_tree
and tuple position methods").

NO_DOC=test
NO_CHANGELOG=test

Now it is accessible using `require('compat')` instead of
`require('tarantool').compat`.

It follows our usual way to expose built-in modules.

It was not done initially due to doubts about projects, which have its
own `myproject/compat.lua` and have modified `package.loaded` to obtain
the project's compat as `require('compat')`.

It is not recommended and should be avoided. Project's modules should be
imported using `require('myproject.<...>')`. Otherwise it may clash with
a future built-in module or any external one.

Follows up #7000

NO_DOC=will be added to https://github.com/tarantool/doc/issues/3259

The patch extends feedback_daemon functionality - now it collects
default metrics if module metrics of required version (>= 0.16.0)
is installed. The metrics are sent as a part of feedback. Feedback
version is bumped.

Closes #8192

@TarantoolBot document
Title: Feedback metrics

Now tarantool collects default metrics and sends it with feedback if
module metrics of required version (>= 0.16.0) is installed. The process
can be tuned with following options:

- `feedback_send_metric` - boolean, collect and send metrics if true.
  Is set to true by default.

- `feedback_metrics_collect_interval` - number, period of metrics
  collection, in seconds. Is set to 60 by default.

- 'feedback_metrics_limit' - number, memory limit for metrics. Is set to
  1024 * 1024 (1 MB) by default.

If required metrics module is not installed or collect always returns nil,
metrics will not present in feedback.

New version of feedback = 8.

Fixed a bug with syslog priority for OS with non-standart `LOG_MAKEPRI`
macro.

Affected all versions for OS: Alpine (including official docker images),
OpenBSD and maybe others.

Fixes #8269

NO_DOC=bugfix
NO_TEST=exists

To support read view listing, we need to add name, id, system flag,
timestamp, vclock, and signature to struct read_view. (Previously they
were stored in Lua read view object implemented in Tarantool EE.)
Also, we have to maintain a registry of all active read views in C.
The registry pursues two goals:

 1. It's used for pushing read view objects (which may be created
    entirely in C, circumventing Lua code) to Lua.
 2. We look up a read view in the registry by id to query the read view
    status ('open' or 'closed') from Lua. This is required so that a
    read view object returned by box.read_view.list() and cached by the
    caller reports the up-to-date status. If a read view isn't found in
    the registry, then it must be closed.

Apart from the C registry of active read views, we also maintain a Lua
registry of all read views that are used in Lua. We add read view
objects returned by box.read_view.list() to this registry so that the
next call would return the same objects. The Lua registry is backed by
a weak table so that it doesn't pin a closed read view object when the
caller drops the last reference to it.

We also intend to move all read view listing machinery from the EE code
to CE (Lua registry, metatables). The EE code will need to override two
methods box.read_view.open() and box.internal.read_view_close(), which
are stubbed out in the CE code. To set the metatable for a read view
object and add it to the registry, EE version of box.read_view.open()
will use box.internal.read_view_register().

Closes #8260

@TarantoolBot document
Title: Document box.read_view.list

The new function returns an array of all active database read views.
It includes both read views created for system purposes (e.g. to make a
checkpoint or join a new replica) and read views created by application
code (this feature is available only in Tarantool Enterprise Edition,
see https://github.com/tarantool/enterprise_doc/issues/194).

Each read view is represented by a table with the following fields:
 - `id` - unique read view identifier.
 - `name` - read view name.
 - `is_system` - true if the read view is used for system purposes.
 - `timestamp` - `fiber.clock()` when the read view was opened.
 - `vclock` - `box.info.vclock` when the read view was opened.
 - `signature` - `box.info.signature` when the read view was opened.
 - `status` - 'open' or 'closed'.

Read views created by application code also have the 'space' field,
which lists all spaces available in the read view, and may be used just
like a read view object returned by `box.read_view.open()`.

The array is sorted by read view id. Since read view ids grow
monotonically, this means that the most recent read view goes last.

Example:

```
tarantool> box.read_view.list()
---
- - timestamp: 4057333.4969064
    signature: 3
    is_system: true
    status: open
    vclock: {1: 3}
    name: join
    id: 3
  - timestamp: 4057357.0874192
    signature: 6
    is_system: true
    status: open
    vclock: {1: 6}
    name: checkpoint
    id: 4
...
```

Move lbox_pushvclock from box/lua/info.c to lua/utils.h so that we can
reuse it. While we are at it, cleanup the header list ln lua/utils.c.

Needed for #8260

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

This patch adds a type check of the first argument of the
tuple_field_by_path() function.

Closes tarantool/security#82

NO_DOC=internal
NO_TEST=internal
NO_CHANGELOG=internal

If `dynamic_cast` fails, then NULL is returned. Even thought
assertion is set, we cannot rely on it, as we don't use debug
version of icu. Let's check if `rbnf` variable is not NULL
explicitly.

If it somehow turned out to be NULL, then memory allocation
error will be thrown.

Closes tarantool/security#61

NO_CHANGELOG=<security fix>
NO_DOC=<security fix>
NO_TEST=<third-party security fix>

According to the business logic and assertions `idx` and `data32`
variables cannot be equal to NULL at the same time. However, we
cannot rely on assertions.

Let's check that explicitly. If this situation occurs somehow
the function exits as we cannot recover from this situation: we
don't have sources, from which values for enumeration can be taken.
Moreover, continuing of the code execution is such situation may
lead to accessing NULL if `c<limit`.

Closes tarantool/security#59

NO_CHANGELOG=<security fix>
NO_DOC=<security fix>
NO_TEST=<third-party security fix>

Closes #8263

NO_DOC=gdb extension
NO_CHANGELOG=gdb extension
NO_TEST=gdb extension

Closes #8312

NO_DOC=gdb extension
NO_CHANGELOG=gdb extension
NO_TEST=gdb extension

Bump the small submodule and use small_getpagesize(), which is a
wrapper over sysconf(_SC_PAGESIZE) with a proper error checking.

Closes tarantool/security#78

NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring

obuf_alloc(&log->zbuf, XLOG_FIXHEADER_SIZE) can potentially fail,
because there is no obuf_reserve() prior to it.

Closes tarantool/security#74

NO_DOC=bugfix
NO_CHANGELOG=bugfix
NO_TEST=no test harness for checking OOM

Commit 3fb0f7f1 ("fix gh-362 and lots of error messages fixes")
introduces an option "dont_check" that disables checks for a certain
parameter. This option is not documented anywhere and looks unusable.
This commit removes it.

Follows up #362

NO_CHANGELOG=internal
NO_DOC=internal
NO_TEST=internal