MVCC repeatable read anomaly with REQ scan

[CuriousGeorgiy]

Discovered with MVCC fuzzing (#5999).

Steps to reproduce

os.execute('rm -rf *.snap *.xlog *.vylog 512')

local json = require('json')
local log = require('log')
local txn_proxy = require('test.box.lua.txn_proxy')

box.cfg{memtx_use_mvcc_engine = true}

box.schema.space.create('v', {engine = 'vinyl'})
box.space.v:create_index('pk')

local tx1 = txn_proxy:new()
local tx2 = txn_proxy:new()

tx1('box.begin()')
tx1('box.space.v:insert{0}')
tx2('box.begin()')
log.info("%s", json.encode(tx2('box.space.v:select({1}, {iterator = "REQ", fullscan = true})')))
tx1('box.commit()')
log.info("%s", json.encode(tx2('box.space.v:get{0}')))

os.exit()

Actual behavior

I> [[]]
I> [[0]]

Expected behavior

I> [[]]
I> [[]]

[locker]

tx1('box.begin()')
tx1('box.space.v:insert{0}')
tx2('box.begin()')
log.info("%s", json.encode(tx2('box.space.v:select({1}, {iterator = "REQ", fullscan = true})')))
tx1('box.commit()')
log.info("%s", json.encode(tx2('box.space.v:get{0}')))

[[]]
[[0]]

This doesn't violate transaction serializability: if tx1 was committed before tx2 started, we'd get the same result.

tx1('box.begin()')
tx1('box.space.v:insert{0}')
tx1('box.commit()')
tx2('box.begin()')
log.info("%s", json.encode(tx2('box.space.v:select({1}, {iterator = "REQ", fullscan = true})')))
log.info("%s", json.encode(tx2('box.space.v:get{0}')))

BTW memtx behavior is exactly the same so this isn't a vinyl issue.

[locker]

Note, replacing the REQ iterator with LE makes get{0} return nothing (again, both in memtx and in vinyl) because in this case tx2 must be serialized before tx1.

[CuriousGeorgiy]

I apologize, I originally confused REQ with LE, and I eagerly reduced the faulty set of operations to this one. I didn't save the original set of operations that triggered it, so this one is lost (or it might have converged again to #11294). Sorry again for the confusion.