Remove released entries.

NO_DOC=minor
NO_TEST=minor
NO_CHANGELOG=minor

When calculating `rows_index` in `netbox_decode_execute` etc we use
implementation defined behavior of compiler. `i < mapsize` and this is
fine according to standard as unsigned arithmetic is well defined on
overflows. But then we cast the result to int and this is implementation
defined as the result can not be represented by int.

Closes https://github.com/tarantool/security/issues/98

NO_DOC=minor
NO_TEST=minor
NO_CHANGELOG=minor

(cherry picked from commit baba38e6)

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

Proofread changelogs for 2.11.0-rc, part 3
Fix grammar, punctuation, and wording

NO_CHANGELOG=changelog
NO_DOC=changelog
NO_TEST=changelog

There is no sense to add description of changes that will be present as
part of 2.10.5 into 2.11.0-rc1 release notes. Let's base the changes
list on current 2.10 (future 2.10.5).

Follows up commit 4d95d1e2 ("Cleanup released changelogs").

NO_DOC=no code changes, just changelogs
NO_TEST=see NO_DOC

In Tarantool EE the version string is "Tarantool Enterprise", not just
"Tarantool".

Fixes commit a984fc0d ("debugger: use option -d for debugger
activation")

NO_DOC=test
NO_CHANGELOG=test

The new compat option 'fiber_slice_default' is added to control
the default value of the max fiber slice. The old default is no limit
(both warning and error slice equals TIMEOUT_INFINITY). The new default
is {warn = 0.5, err = 1.0}.

Follow-up #6085

NO_DOC=tarantool/doc#3057
NO_CHANGELOG=unreleased

This commit adds the new field 'max_slice' to fiber.info() that reports
the max slice applied to the given fiber. The value is a table with two
fields: 'err' for error slice and 'warn' for warning slice. Values
greater than or equal to TIMEOUT_INFINITY aren't reported.

Follow-up #6085

NO_DOC=tarantool/doc#3057
NO_CHANGELOG=unreleased

Error messages raised when an invalid slice is specified are confusing:

  tarantool> fiber = require('fiber')
  ---
  ...

  tarantool> fiber.set_max_slice('foo')
  ---
  - error: slice must be a table or a number
  ...

  tarantool> fiber.set_max_slice({})
  ---
  - error: 'bad argument #3 to ''?'' (number expected, got nil)'
  ...

Let's change the error message to "slice must be a number or a table
{warn = <number>, err = <number>}".

Follow-up #6085

NO_DOC=undocumented
NO_CHANGELOG=unreleased

One may encode a non-printable string under the MsgPack type MP_STR.
In fact, there's no way to encode binary data as MP_BIN from Lua so
users often do that, which breaks our gdb extension. Let's encode a
string in base64 if unicode() raises an error, like we do with MP_BIN.

While we are at it,
 - escape double quotes in printable strings;
 - fix MP_BIN encoding (b64encode takes and returns bytes).
 - don't use YAML !!binary prefix before base64 data - use bin: and str:
   instead.

Here's what it looks like:

```
(gdb) p *box_tuple_last
  <...>
  data = ["\"тест\\foo\"", str:/w==, bin:/w==]}
```

The tuple was created with the following command:

```
tarantool> msgpack = require('msgpack')
---
...

tarantool> box.tuple.new(
         >   msgpack.object_from_raw('\xae"тест\\foo"'), -- MP_STR unicode
         >   msgpack.object_from_raw('\xa1\xff'),        -- MP_STR binary
         >   msgpack.object_from_raw('\xc4\x01\xff'))    -- MP_BIN
---
- ['"тест\foo"', !!binary /w==, !!binary /w==]
...
```

Follow-up commit 08a171a4 ("gdb: support unicode in MP_STR type of
MsgPack").

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

It doesn't belong to Tarantool sources. The tools directory looks like
the right place for it.

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

This patch allows to downgrade tuple foreign keys to SQL foreign keys
and some tuple check constraints to SQL check constraints. The only
tuple check constraints that can be downgraded are those using functions
with the SQL_EXPR language.

Closes #7718

NO_DOC=already introduced
NO_CHANGELOG=already introduced

Added `-d` option for activation of debugger shell:
- it calls debugger shell in `luadebug.lua` instead of
  a standard interactive shell from `console.lua`;
- that option complements original way for starting a
  debugging shell via `require 'luadebug'()`, but is a
  little bit easier.

NB! At the moment when we enter debugging mode instead of
a standard Tarantool console, we change banner to:
```
Tarantool debugger 2.11.0-entrypoint-852-g9e6ed28ae
type 'help' for interactive help
```

Part of #7456

@TarantoolBot document
Title: Command-line option `-d` for console debugger.

Please see third_party/lua/README-luadebug.md for a full description
of different ways to activate debugging shell.

* ci: add LUAJIT_ENABLE_CHECKHOOK for exotic matrix
* ci: add ARM64 architecture to exotic testing
* ci: update action/checkout to v3
* Fix os.date() for wider libc strftime() compatibility.
* x86/x64: Fix loop realignment.
* ci: introduce workflow for exotic builds
* sysprof: fix interval parsing in dual-number mode
* test: add test for `string.format('%c', 0)`
* ci: drop obsolete arguments for LuaJIT integration

Part of #8069

NO_DOC=LuaJIT submodule bump
NO_TEST=LuaJIT submodule bump

2.10.5 version is going to be released at the same time as 2.11.0 thus
let's add it to the box.schema.downgrade_versions().

NO_DOC=internal
NO_CHANGELOG=internal
NO_TEST=internal

Currently it's possible to set the log level for a particular Lua module,
or to change the default log level, however there is no way to change it
only for Tarantool system messages. This patch introduces a fake module
name "tarantool" for this purpose.

Closes #8320

NO_CHANGELOG=Unreleased feature
NO_DOC=Will update tarantool/doc#3264

We used to "normalize" breakpoint filename paths
down to their basic name, which worked fine for
unique file names, but is getting annoying when
you need to debug a code in one of many `init.lua`
modules, i.e.

    break init.lua:5

Will stop at _every_ `init.lua` file we will run
at the debugging session.

So we add machinery for partial paths lookup, to
make possible to set breakpoints using (unique-enough)
path suffixes, e.g. if we have multiple `init.lua` in
the application, i.e.
    ./init.lua
    ./A/init.lua
    ./B/init.lua

Then we could use syntax:

    break A/init.lua:5

To activate debugger breakpoint only in the particular
module, and not trigger it elsewhere.

Current suffix trees limitations and peculiarities
--------------------------------------------------

Please keep in mind that suffix-tree algorithm, used for
partial paths lookup, uses `$ref` and `$f` node names
for their own purposes. That means that it would not handle
well breakpoints with paths containing `$f` and `$ref`.
That's not a big problem given that majority of filesystems
we are running on do not usually allow `$` as part of
file name.

Also, due to suffix tree lookup behavior, if we would
activate multiple breakpoints:
    break init.lua:10
    break A/init.lua:10

Then _least specific_ `init.lua:10` breakpoint will trigger.
From users' prospective it makes no much difference, as we
need to stop in debugger shell in this line, but this is
the way how suffix tree is working.

Dot files treatment
-------------------

There is a special mechanism for `.` and `..` treatment
if they are at the header of a path provided. I.e.

    break ./main.lua:10
    break ../a/b/c/least.lua:15

For these cases `.` and `..` will be converted to the
full path to the given file location.

NO_TEST=hard to implement tests. Postponed till step.5

@TarantoolBot document
Title: Breakpoints in console debugger for Lua

Match partial path patterns in breakpoints
==========================================

Please see `third_party/lua/README-luadebug.md` for
a fuller description of partial path syntax one could use
in a breakpoints definition.

We used to "normalize" breakpoint filename paths
down to their basic name, which worked fine for
unique file names, but is getting annoying when
you need to debug a code in one of many `init.lua`
modules, i.e.

    break init.lua:5

Will stop at _every_ `init.lua` file we will run
at the debugging session.

So we add machinery for partial paths lookup, to
make possible to set breakpoints using (unique-enough)
path suffixes, e.g. if we have multiple `init.lua` in
the application, i.e.
    ./init.lua
    ./A/init.lua
    ./B/init.lua

Then we could use syntax:

    break A/init.lua:5

To activate debugger breakpoint only in the particular
module, and not trigger it elsewhere.

NB! If we will activate multiple breakpoints:
    break init.lua:10
    break A/init.lua:10

Then _least specific_ `init.lua:10` breakpoint will trigger.
From users' prospective it makes no much difference, as we
need to stop in debugger shell in this line, but this is
the way how suffix tree is working.

NO_TEST=hard to implement tests. Postponed till step.5

@TarantoolBot document
Title: Breakpoints in console debugger for Lua

Match partial path patterns in breakpoints
==========================================

Please see `third_party/lua/README-luadebug.md` for
a fuller description of partial path syntax one could use
in a breakpoints definition.

* Added breakpoints support in debugger;

NO_TEST=documentation added

@TarantoolBot document
Title: Breakpoints in console debugger for Lua

Breakpoints support
===================

Please see `third_party/lua/README-luadebug.md` for
a description of breakpoints support introduced to the
builtin console debugger in `luadebug.lua`.

Commonize mechanism activated by `dbg.cfg.auto_where` and an
automatic code listing we show for breakpoint context.

Make sure we do not show redundant listing, i.e. after
commands `where #`, or `up`, or `down` we do not output
automatic listing, as there was already shown some different
context.

NO_DOC=see later
NO_CHANGELOG=internal
NO_TEST=internal

Make message, which is shown for a `help` command,
to be more readable.

NO_DOC=see later commit
NO_CHANGELOG=internal
NO_TEST=internal

Introduced `dbg_write_error` to centralize the way
how errors reported in debugger shell.

Similarly `dbg_write_warn` is used for reporting of
highlighted non-fatal warnings.

NO_DOC=internal
NO_CHANGELOG=internal

We may use "caret" or "arrow" symbols either in
colored or uncolored contexts. To reduce further
confusion we get rid of colored prefixes.

NO_DOC=internal
NO_CHANGELOG=internal
NO_TEST=internal

In many cases we do not need to use all "Snl"
parameters in `debug.getinfo()`: so try to trim wherever
possible "n", which is calculating `name` and `namewhat`,
and "S" which is generating `source`, `short_src` and others.

NO_DOC=internal
NO_CHANGELOG=internal
NO_TEST=internal

Visualize properly locations with breakpoints
saved there. In addition to current line visualization
(using green '=>') we annotate corresponding line with
red "●".

NO_TEST=see the later commit
NO_DOC=internals
NO_CHANGELOG=internals

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 situation.

`assert()` works only in Debug build, but most of user's code is tested
on RelWithDebInfo builds. So incorrect override module may be
implemented and distributed. It is undesirable.

Let's replace `assert()` with explicit `panic()`.

Adjusted testing helpers:

* `treegen` now allows to just write given script into given directory
  without using templates. Sometimes it is more convenient.
* `justrun` can return pure stdout (without JSONL decoding) and can
  return stderr if requested.

`nojson` option in `justrun` may look unneeded for given test cases, but
it provides better diagnostics if something going wrong and one of the
test cases fails (say, if tarantool runs successfully instead of going
to panic).

Follows up #7774

NO_DOC=The override modules feature is not released yet.
NO_CHANGELOG=see NO_DOC

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.