The patchset enforces serializable isolation by addressing the following MVCC bugs:

• Rollback may cause duplicates in secondary indexes.
  To guarantee the absence of duplicates in secondary indexes, MVCC maintains the following invariant for all in-progress transactions:

  If an in-progress story `x` conflicts with a story `y` in some secondary index
  (i.e., they have the same key in that index), then `x` must also conflict with `y` in the primary key.
  

  x and y may belong to the same transaction or different ones. The case where x and y belong to the same transaction is trivial. If x and y belong to different transactions, then y must be the last prepared story in the chain corresponding to that index. This implies that the invariant may break for some transactions when the last prepared story in a chain changes (either when another story becomes last or when the last story's del_psn becomes 0). All such cases must be handled - any transactions that violate the invariant (i.e., start duplicating prepared tuples) must be aborted.

  Rollback often leads to changes in the last prepared story within chains. However, this case was previously overlooked, which could result in duplicates after rollback. This patch adds the missing handling for rollback scenarios.

  Closes mvcc: rollback may cause duplicates in secondary indexes #11660

• Insert-after-delete in single transaction may cause duplicates in secondary indexes.
  The issue was related to MVCC assuming that if it inserts a tuple x={key, ...} that doesn't conflict with any other tuple on the primary key key (because it previously executed delete(key) removing some tuple y={key, ...} with the same primary key), then x couldn't possibly be a duplicate in any secondary index. However, this is obviously false. To make such a conclusion for a specific secondary index, the deleted tuple y must have the same key value in that index as tuple x.

  The problem was connected with the is_own_change flag in the transactional statement. Its truth or falsity did not allow us to say anything about secondary indices.

  Similar flags were introduced separately for each index. The statement-level flag remains, but it now has a different name (is_own_delete) and semantics. This flag is only used for DELETE statements; for INSERT/REPLACE, it is always false. delete_stmt->is_own_delete means the statement will either delete some tuple from the same transaction or won't delete anything because the same transaction previously deleted this key.

  For INSERT/REPLACE statements, stmt->is_own_change has been replaced by stmt->add_story->link[0].is_own_change, which is equivalent to the stmt->is_own_change that existed before this commit.

  Closes mvcc: insert-after-delete in single transaction may cause duplicates in secondary indexes #11686

• Get-after-replace in single transaction may cause dirty read in secondary index.
  The issue was related to MVCC assuming that if it performed a replace with a new tuple x={key, ...} that also deleted some tuple y={key, key2} with the same primary key, then a subsequent index.sk:get(key2) in the same transaction wouldn't return anything. This would be true if the transaction had deleted y using delete rather than replace, because delete guarantees it will definitely remove exactly what was returned to the user (it tracks reads if y was inserted by another transaction, or y was inserted by the same transaction, in which case this guarantee arises automatically).

  This issue was automatically fixed by the same is_own_change flag-related fix described above. Now when MVCC performs get on a secondary key, it checks the is_own_change flag for that secondary index and determines whether it can automatically guarantee it won't read anything, or whether it needs to create a gap tracker to enforce this guarantee.

  Closes mvcc: get-after-replace in single transaction may cause dirty read in secondary index #11687

• Rollback may cause dirty gap read in secondary index.
  The essence of the problem: One REPLACE transaction (prepared but not yet committed) creates a temporary situation where another concurrent transaction cannot see a specific key in a secondary index (a "read gap"). When the first transaction then rolls back, the previous (replaced) tuple becomes visible again, and the "read gap" becomes irrelevant (the key becomes visible once more). In this case, the second transaction, which read the gap, should be aborted. However, it successfully commits, leading to a non-serializable schedule.

  This patch fixes the issue by adding the necessary handling during rollback. Now, all such irrelevant gaps are aborted.

  Closes mvcc: rollback may cause dirty gap read #11802