Integrate MVCC

[penberg]

This draft pull request integrates MVCC into the core.

The plan is to implement SQLite BEGIN CONCURRENT by introducing a "MV store" abstraction (that implements the Hekaton in-memory MVCC index) above the pager. Traditional SQLite transactions use the pager and the WAL, but MV store has its own transaction path that updates the in-memory multi-versioned index. If a key does not exist in the MVCC index, we read records from the pager. When a MVCC transaction commits, we emit WAL entries.

Allowing BEGIN CONCURRENT and traditional transactions to run at the same time is a bit tricky. If we don't coordinate between them, we can have lost updates and read skew.

Lost update happens when:

• Traditional TX1 reads value A
• CONCURRENT TX2 reads value A
• TX1 updates to B
• TX2 updates to C based on A

Read skew happens when:

• CONCURRENT TX1 reads table 1
• Traditional TX2 updates tables 1 and 2
• TX1 reads table 2
• TX1 sees inconsistent snapshot (old table 1, new table 2)

There are few options to solve this problem:

1. Make all transactions go through the MV store and emulate the SQLite traditional transaction semantics in the VDBE layer. This is probably the best long-term solution, but we might want to give MVCC more mileage before doing this.
2. Notify MV store when a traditional transaction commits allowing it to create new versions of the updated records. This seems to be tricky to get right, though.
3. Disallow mixed style transactions and require the application to opt-in to MVCC via connection open flag. This seems most straight-forward.

ToDo:

• Implement MVCC cursor and use it
• Read transparently from pager if key is not in MV store
• BEGIN CONCURRENT support
• Emit WAL at MVCC transaction commit