Implement per-transaction schema versioning to eliminate table-level DDL locks - Step 1

MariaDB acquires a table-level metadata lock (MDL) during DDL execution, blocking concurrent DML on the affected table. This causes availability degradation in high-throughput OLTP environments, especially in distributed setups where DDL propagation latency amplifies the lock duration.
Implement schema versioning so that each transaction operates against the schema version captured at its start_ts. Concurrent DDL creates a new schema version without blocking in-flight transactions — they continue using their snapshot. New transactions after DDL commit observe the updated schema.
This is analogous to MVCC for data but applied to schema metadata.
Example of the current problem:

-- Session 1: long-running DDL blocks all DML

ALTER TABLE orders ADD COLUMN priority INT DEFAULT 0;

-- Session 2: blocked until ALTER completes

UPDATE orders SET status = 'shipped' WHERE id = 42;

Expected behavior: Session 2 proceeds using the pre-ALTER schema version; new transactions after ALTER commit see the new column.

In this issue will do only the first part:

Server-Side Schema Versioning Infrastructure (Core Server / MDL)

• Estimated Effort: ~10-12 mandays
• Goal: Modify the MariaDB server layer to understand, store, and serve multiple concurrent table definitions without breaking existing single-version assumptions.
• Key Technical Tasks:
  • Table Definition Cache (TDC) Updates: Refactor the TDC so it can hold multiple versions of the same table structure concurrently, rather than a single global definition.
    Transaction-Schema Mapping: Introduce logic to bind a transaction's start_ts to a specific schema version. The server must be able to resolve which table structure a specific transaction should see.
  • MDL Subsystem Changes: Modify the Metadata Lock (MDL) manager. Instead of the DDL thread requesting an exclusive MDL that blocks all other operations at the end of the DDL, introduce a mechanism (like a versioned MDL) that allows existing transactions to retain their shared lock on the "old" schema version.
  • Validation: At the end of this phase, the server can theoretically handle multiple schema versions in memory, even if the storage engine doesn't yet exploit this for non-blocking commits.