It's possible to commit a write transaction after becoming read-only with mvcc

[sergepetrenko]

Bug description

Tarantool version: 3.1.0-entrypoint-234-g4466deafee

Our read-only checks only work when corresponding write statements are executed, and not on transaction commit.
So if code executing a transaction writes something and then yields before commit (which's possible with MVCC), and the node becomes read-only during this yield, the commit will happen anyway, writing data on a read-only node.

Since the WAL write is initiated only on transaction commit, this means a node may continue writing data after becoming read-only, breaking all the expectations about being read-only.

Steps to reproduce

Run a single tarantool instance in interactive mode and issue:

-- Step 1.
box.cfg{memtx_use_mvcc_engine = true}
s = box.schema.space.create('test')
_ = s:create_index('pk')

-- Step 2.
fiber = require('fiber')
log = require('log')
fiber.new(function()
    box.begin()
    log.info("read-only status before yield is %s", box.info.ro)
    s:insert{1}
    fiber.sleep(5)
    log.info("read-only status after yield is %s", box.info.ro)
    box.commit()
end)
box.cfg{read_only = true}

-- Step 3. Wait a bit (until the transaction above is committed), then do:
s:fselect{}

Actual behavior

During step 2 the logs will show:

2024-04-11 13:47:18.040 [30674] main/117/lua/tarantool I> read-only status before yield is false
tarantool> box.cfg{read_only = true}
2024-04-11 13:47:18.345 [30674] main/104/interactive/box.load_cfg I> set 'read_only' configuration option to true
2024-04-11 13:47:23.038 [30674] main/117/lua/tarantool I> read-only status after yield is true

And step 3 output:

tarantool> s:fselect{}
---
- |-
  +-----+
  |col1 |
  +-----+
  |  1  |
  +-----+
...

Expected behavior

box.commit() from the example above should fail and throw an error.
Something like: The node became read-only while the transaction was processed.