The patch bumps Clang version from 16 to 19 in workflows that intended to use the most modern Clang version. Many things were changed since version 16, see release notes in [1], [2], [3]. The `-Ofast` command-line option has been deprecated in Clang 19, see [3]. It is advised to switch to `-O3 -ffast-math` if the use of non-standard math behavior is intended, and -O3 otherwise. The patch replaces `-Ofast` with `-O3 -ffast-math` to suppress a message below in a build log: NO_WRAP clang-19: warning: argument '-Ofast' is deprecated; use '-O3 -ffast-math' for the same behavior, or '-O3' to enable only conforming optimizations [-Wdeprecated-ofast] NO_WRAP The bump had needed an update of Dockerfile used for building Docker image used in aforementioned workflows, see pull request in [4]. 1. https://releases.llvm.org/17.0.1/tools/clang/docs/ReleaseNotes.html 2. https://releases.llvm.org/18.1.6/tools/clang/docs/ReleaseNotes.html 3. https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html 4. https://github.com/tarantool/infra/pull/206 NO_CHANGELOG=build NO_DOC=build NO_TEST=build

The new version of the publishing action leads to the following error: NOWRAP ``` Error: File not found: '/home/runner/work/_actions/JamesIves/github-pages-deploy-action/v4.6.6/lib/main.js' ``` NOWRAP Let's revert it to v4.6.4 (because v4.6.5 change was reverted in v4.6.6). See also https://github.com/JamesIves/github-pages-deploy-action/issues/1697 NO_DOC=no code changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The `ubuntu-latest` image is now `ubuntu-24.04`, see [1]. The job fails on this image with the following error: NOWRAP ``` CMake Error at /usr/local/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message): Could NOT find Readline (missing: READLINE_INCLUDE_DIR READLINE_LIBRARY) ``` NOWRAP It seems, the libreadline-dev package is missing. Let's install it. Also, update a version of the publishing action to the latest at the moment. I didn't perform any check, but I guess that a new version of NodeJS is needed and the latest action version has better support of it. [1]: https://github.blog/changelog/2024-09-25-actions-new-images-and-ubuntu-latest-changes/ NO_DOC=no code changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

The cluster helper in `test/config-luatest/cluster.lua` is used to define the clusters in an easy way. Though every time the `cluster.new` is called it creates a new temporary directory, which is not good when you're writing a test setting up the directory before the cluster start. This patch adds an `opts` object as the fourth parameter for `cluster.new` and makes the function use `opts.dir` as a key for specifying the directory to start the cluster. Example: ``` local dir = '/some/long/dir' local cluster_config = cbuilder:new(remote_config) :use_replicaset('r-001') :add_instance('i-001', {}) :config() -- The cluster will be started in a new temp directory. local cluster = cluster.new(g, cluster_config) -- The cluster will be started in '/some/long/dir'. local cluster = cluster.new(g, cluster_config, nil, { dir = dir }) ``` Needed for testing tarantool/tarantool-ee#870. NO_CHANGELOG=internal testing helper change NO_TEST=internal testing helper change NO_DOC=internal testing helper change

This patch introduces the ability to grant execution privileges for Lua functions through declarative configuration, even when the database is in read-only mode or has an outdated schema version. Users can specify `lua_call: [<func_name>]`, enabling the execution of specified Lua functions (e.g., `failover:execute()` when all instance are in read-only mode). The `lua_call: [all]` option is also supported, allowing access to all global Lua functions except built-in ones, regardless of database mode or status. Privileges are still written to the database when possible for consistency and compatibility. Closes tarantool#10310 @TarantoolBot document Title: Grant runtime access to Lua functions via configuration It is now possible to grant execution privileges for Lua functions through the declarative configuration, even when the database is in read-only mode or has an outdated schema version. You can specify function permissions using the `lua_call` option in the configuration, for example: ```yaml credentials: users: alice: privileges: - permissions: [execute] lua_call: [my_func] ``` This grants the `alice` user permission to execute the `my_func` Lua function, regardless of the database's mode or status. The special option `lua_call: [all]` is also supported, granting access to all global Lua functions except built-in ones, bypassing database restrictions. Privileges will still be written to the database when possible to maintain compatibility and consistency with other privilege types.