lookaside for primary keys. Replaces #344

[tantaman]

Replaces #344

TODO:

• [x] Update trigger functions to lookup from lookaside first
• [x] Update vtab to join in lookaside on read
• [x] Update vtab to merge using lookaside
• Move sentinel record to lookaside? : not doing this since it makes pulling changes quite difficult.
• [x] Backfill logic & automigrate logic
• [ ] rowid fixup?
  • key * 100 + col_offset
  • search thru everywhere in rust code for rowid and swap to new algorithm

Test key creation:

• Stable rowid in all circumstances (re-insert, update, insert, delete, insert or ignore/replace/onconflict)
• Always exists after each op
• Created for mergers of new rows
• Not created for merges of existing rows
• Not created or deleted for merges of existing rows that are deleteed
• Created for mergers of deletions for unseen rows

[tantaman]

There's a regression to insert performance (https://github.com/vlcn-io/cr-sqlite/blob/c26d2f8a088fadc1cdca7b592f8cb73101e8feff/py/perf/perf.ipynb). Apparently writing an extra table is a heavy (~20%) hit. Update performance is improved by ~15% though. Makes sense since updates do not have to write to the lookaside table -- the row is already there.

This is probably worth it given the storage savings. Users will most likely use uuids for primary keys in CRRs so we can save ~12-14 bytes per column with this. For users with compound primary keys, the savings are greater.

---

Still a number of failing integration tests.

[tantaman]

@jeromegn - everything looks good if you want to give it a spin.

I'm going to write a few more tests still before merging.

[jeromegn]

Nice!

What about the remaining tasks? I fear they'd require a new migration.

[tantaman]

The rowid change will not since virtual tables don't actually save a rowid.

I don't think I'm going to move the sentinel information out of the clock tables since it will require ordering another set of tables when reading changes out.