CMake 3.29.0 produces a warning on configuration stage: | CMake Warning (dev) in cmake/ProtobufMutator.cmake: | A logical block opening on the line | /home/sergeyb/sources/MRG/tarantool/cmake/ProtobufMutator.cmake:38 (if) | closes on the line | /home/sergeyb/sources/MRG/tarantool/cmake/ProtobufMutator.cmake:40 (endif) | with mis-matching arguments. The patch fixes the warning. NO_CHANGELOG=build NO_DOC=build NO_TEST=build

An attempt to build Tarantool statically by Ninja (with the enabled CMake option BUILD_STATIC_WITH_BUNDLED_LIBS), error below is produced: | ninja: error: build.ninja:1405: bad $-escape | (literal $ must be written as $$) The commit fixes that error. Follows up commit c92a1699d6c8 ("cmake: support build using Ninja"). NO_CHANGELOG=build NO_DOC=build NO_TEST=build

CMake 3.24+ produces a warning about the missed option DOWNLOAD_EXTRACT_TIMESTAMP in `ExternalProject_Add()` [1]: | The DOWNLOAD_EXTRACT_TIMESTAMP option was not given and policy | CMP0135 is not set. Documentation about policy CMP0135 [2] said: CMake 3.23 and below set the timestamps of the extracted contents to the same as the timestamps in the archive. When the URL changes, the new archive is downloaded and extracted, but the timestamps of the extracted contents might not be newer than the previous contents. Anything that depends on the extracted contents might not be rebuilt, even though the contents may change. CMake 3.24 and above prefer to set the timestamps of all extracted contents to the time of the extraction. This ensures that anything that depends on the extracted contents will be rebuilt whenever the URL changes. 1. https://cmake.org/cmake/help/latest/module/ExternalProject.html#url 2. https://cmake.org/cmake/help/latest/policy/CMP0135.html NO_CHANGELOG=build NO_DOC=build NO_TEST=build

Remote replica's vclock is given to master to send data starting from that position. The master does that, but, in order to find the relevant position in local WAL to start from, the master must ignore the local rows. Consider them all already "sent". For that the master replaces the remote vclock[0] with the local vclock[0]. That makes xlog cursor skip all the local rows. The problem is that this vclock was taken by relay as is, like if it was truly reported by the replica. It was even saved as the "last received ACK". Which clearly isn't the case. When a real ACK was received, it didn't contain anything in vclock[0], and yet relay "saw" that the previous ACK has vclock[0] > 0. That looked like the replica went backwards without even closing connection, which isn't possible. That made the relay crash from cringe (on assert). The fix is not to save the local vclock[0] in the last received ACK. For GC and xlog cursor the hack is still needed. An option how to make it easier was to set vclock[0] to INT64_MAX to just never even bother with any local rows, but that didn't work. Some assumptions in other places seem to depend on having a proper local LSN in these places. Closes #10047 NO_CHANGELOG=the bug wasn't released NO_DOC=bugfix

It wasn't clear which of them are inputs and which are outputs. The patch explicitly marks the input vclocks as const. It makes the code a bit easier to read inside of relay.cc knowing that these vclocks shouldn't change. Alongside "replica_clock" in subscribe is renamed to "start_vclock". To make it consistent with relay_final_join(), and to signify that technically it doesn't have to be a replica vclock. It isn't really. Box.cc alters the replica's vclock before giving it to relay, which means it is no longer "replica clock". In scope of #10047 NO_TEST=refactoring NO_CHANGELOG=refactoring NO_DOC=refactoring

GC consumer creation and destroy seemed to only happen in box.cc with one exception in relay_subscribe(). Lets move it out for consistency. Now relay can only notify GC consumers, but can't manage them. That also makes it harder to misuse the GC by passing some wrong vclock to it, similar to what was happening in #10047. In scope of #10047 NO_TEST=refactoring NO_CHANGELOG=refactoring NO_DOC=refactoring

The function takes the burden of explaining why this hack about setting local component in a remote vclock is needed. It also creates a new vclock, not alters an existing one. This is to signify that the vclock is no longer what was received from a remote host. Otherwise it is too easy to actually mistreat this mutant vlock as a remote vclock. That btw did happen and is fixed in following commits. In scope of #10047 NO_TEST=refactoring NO_CHANGELOG=refactoring NO_DOC=refactoring

The source files for built-in Lua modules are generally placed on the same level: in `src/lua` or in `src/box/lua`, disregarding whether they're public or internal. The recently introduced `experimental.connpool` built-in module is placed in the `experimental` subdirectory. This commit moves `src/box/lua/experimental/connpool.lua` to `src/box/lua/connpool.lua` to follow the existing file structure. Public, internal and experimental modules are all on the same level now. The `connpool` module is still experimental and `require('experimental.connpool')` is needed to use it. This commit doesn't change the code of the module. NO_DOC=no code changes NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC

Currently, the demoted leader sees that nobody has requested a vote in the newly persisted term (because it has just written it without voting, and nobody had time to see the new term yet), and hence votes for itself, becoming the most probable winner of the next elections. To prevent this from happening, let's forbid the demoted leader to be a candidate in the next elections using `box_raft_leader_step_off`. Closes #9855 NO_DOC=<bugfix> Co-authored-by: Serge Petrenko <sergepetrenko@tarantool.org>

Suggested by Nikita Zheleztsov in the scope of #9855. Needed for #9855 NO_CHANGELOG=<refactoring> NO_DOC=<refactoring> NO_TEST=<refactoring> Co-authored-by: Nikita Zheleztsov <n.zheleztsov@proton.me>