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