There is no check for NULL for a value returned by `ibuf_alloc`, the NULL will be passed to `memcpy()` if the aforementioned function will return a NULL. The patch fixes that by replacing `ibuf_alloc` with macros `xibuf_alloc` that never return NULL. Found by Svace. NO_CHANGELOG=codehealth NO_DOC=codehealth NO_TEST=codehealth (cherry picked from commit b4ee146fde6e418aed590ac6054cff75c2a59626)

This patch optimizes the process of collecting ACKs from replicas for synchronous transactions. Before this patch, collecting confirmations was slow in some cases. There was a possible situation where it was necessary to go through the entire limbo again every time the next ACK was received from the replica. This was especially noticeable in the case of a large number of parallel synchronous requests. For example, in the 1mops_write bench with parameters --fibers=6000 --ops=1000000 --transaction=1, performance increases by 13-18 times on small clusters of 2-4 nodes and 2 times on large clusters of 31 nodes. Closes #9917 NO_DOC=performance improvement NO_TEST=performance improvement (cherry picked from commit 4a866f64d64c610a3c8441835fee3d8dda5eca71)

Two new vclock methods have been added: `vclock_nth_element` and `vclock_count_ge`. * `vclock_nth_element` takes n and returns whatever element would occur in nth position if vclock were sorted. This method is very useful for synchronous replication because it can be used to find out the lsn of the last confirmed transaction - it's simply the result of calling this method with argument {vclock_size - replication_synchro_quorum} (provided that vclock_size >= replication synchro quorum, otherwise it is obvious that no transaction has yet been confirmed). * `vclock_count_ge` takes lsn and returns the number of components whose value is greater than or equal to lsn. This can be useful to understand how many replicas have already received a transaction with a given lsn. Part of #9917 NO_CHANGELOG=Will be added in another commit NO_DOC=internal (cherry picked from commit 58f3c93b660499e85f08a4f63373040bcae28732)

According to the C standard, passing `NULL` to `memcpy` is UB, even if it copies nothing (number of bytes to copy is 0). The commit fixes such situation in memtx MVCC. Closes tarantool/security#129 NO_TEST=fix UB NO_CHANGELOG=fix UB NO_DOC=fix UB (cherry picked from commit 24d38cef5adff900bea2484235762678ac1c5234)

Since commit e19bca5a74e8 ("box: check fiber slice in generic implementation of index count"), Vinyl's version of `index.count()` checks the fiber slice. As a result, the test may fail if it runs under a heavy load: ``` | @@ -94,6 +94,7 @@ | end | end; | | --- | + | - error: fiber slice is exceeded | | ... | -- Verify that at any moment max index is corresponding to amount of tuples, | -- which means that changes apply order is correct ``` Let's set the max fiber slice to a big value to avoid that. NO_DOC=test fix NO_CHANGELOG=test fix (cherry picked from commit b5fb66437a22ea65ed27c2ed14636e8036b079d3)