Stress-test parallel execution (InnoDB part)

Parallel execution implements the idea of splitting an InnoDB table or a index into chunks and processing them in parallel. An InnoDB table is a clustered (primary) index itself, so both primary and secondary indexes are being split in the same manner.

The InnoDB part of parallel execution includes:

• partitioning a full index or a given range into chunks;
• storing chunks beginnings and ends;
• providing chunks to workers on demand;
• positioning on the beginning of a chunk (or a range), moving to next record, checking the end of a chunk or a range;
• re-partitioning some chunks into smaller ones.

Indexes in InnoDB are B-Trees which are automatically rebalanced, which implies changing of the tree shape. When more records are inserted, some pages of the tree may split into two, and the tree may grow in depth (more levels of the tree are added).
And the reverse holds: when data is deleted, sparse pages may be merged together, and the tree may shrink in depth.

The B-Tree re-shaping may occur concurrently on any stage of a parallel query processing: partitioning, positioning, moving the next record. The goal of the task is to make sure that some concurrency issues have not slipped into the code.

The idea: multiple writers concurrently modify the B-Tree by inserting or deleting rows (this should cause multiple page splits, and potentially addition of tree levels). At the same time, another reader executes a long-running parallel query. We want to verify there are no crashes or incorrect results returned to the reader. The similar scenario should be replayed during merging of InnoDB pages, i.e., when writers delete data.

I attach a script that Claude generated for me, it can be used as a sample. It probably makes sense to experiment with a different table structure (wider records consume more space, so page splits are expected more frequently).

Branch for testing: bb-13.2-MDEV-40012-refactored-input3. Preferrably both Debug and Release builds.