Generate changelog for 3.1.2 Also, remote unreleased/ entries and add a new downgrade version to downgrade versions list. NO_DOC=changelog NO_TEST=changelog NO_CHANGELOG=changelog

vinyl: do not discard run on dump/compaction abort if index was dropped If an index is dropped while a dump or compaction task is in progress we must not write any information about it to the vylog when the task completes otherwise there's a risk of getting a vylog recovery failure in case the garbage collector manages to purge the index from the vylog. We disabled logging on successful completion of a dump task quite a while ago, in commit 29e2931c66c5 ("vinyl: fix race between compaction and gc of dropped LSM"), and for compaction only recently, in commit ae6a02ebab0b ("vinyl: do not log dump if index was dropped"), but the issue remains for a dump/compaction failure, when we log a discard record for a run file we failed to write. These results in errors like: ``` ER_INVALID_VYLOG_FILE: Invalid VYLOG file: Run 6 deleted twice ``` or ``` ER_INVALID_VYLOG_FILE: Invalid VYLOG file: Run 5768 deleted but not registered ``` Let's fix these issues in exactly the same way as we fixed them for successful dump/compaction completion - by skipping writing to vylog in case the index is marked as dropped. Closes #10452 NO_DOC=bug fix (cherry picked from commit de59504c2bdb0369cdd27af892301f8515293fe1)

memtx: skip excluded tuples in index count with MVCC enabled Excluded tuples actually have their own history chains in MVCC - such chains consist of only one `memtx_story` containing excluded tuple itself. Such chains should be skipped when counting invisible tuples because they are not inserted to the index - that's what the commit does. Closes #10396 NO_DOC=bugfix (cherry picked from commit 8947cb04f59423e2944d48b8a1effec2fb11b1db)

memtx: do not pass pagination key to MVCC Currently, when starting an iterator in memtx tree on a range request, we pass key from `start_data` to memtx MVCC. The problem is `start_data` can contain pagination key that is extracted with `cmp_def`, but MVCC performs all comparisons with `key_def`. Fortunately, first parts of `cmp_def` is actually `key_def` of the index, so let's crop `start_data` by passing `part_count` not greater than `key_def->part_count` to MVCC. Closes #10448 NO_DOC=bugfix (cherry picked from commit 0dca0076c0fdaee142020cdeddb031bc0e2238cb)

vinyl: enable exact match optimization for unique secondary indexes If the iterator type is EQ/REQ/LE/GE and the search key is exact (that is, there may be at most one tuple matching the key in the index), there's no need to scan disk levels if we found a statement for this key in the memory level. We've had this optimization for ages but it worked only for full keys in terms `cmp_def` (key definition extended with primary key parts). Apparently, a lookup in a secondary index performed by the user wouldn't match these criteria unless the secondary index explicitly included all primary key parts. This commit improves on that. Now, we enable the optimization if the search key is **exact**. We consider a key **exact** if either of the following conditions is true: - The key statement is a tuple (tuple has all key parts). - The key statement is a full key in terms of `cmp_def`. - The key statement is a full key in terms of `key_def`, it doesn't contain nulls, and the index is unique. The check for nulls is necessary because even a unique nullable index may contain more than one equal key with nulls. Note, this patch slightly refactors the optimization, adding a few comments and hopefully making it more understandable. In particular, we remove the one-result-tuple optimization for exact EQ/REQ from `vy_read_iterator_advance` and put it in `vy_read_iterator_evaluate_src` instead. This way the whole optimization resides in one place. Closes #10442 NO_DOC=bug fix (cherry picked from commit 850673db5a69df2c7250d174ab15305624b2634a)