Vastly speed up ancestry check by not re-crawling duplicate histories.

[ChrisPenner]

Overview

Noticed when doing fast-forward detection in PG that base only has ~500 history nodes at the top level, so was curious why it was infeasible to do full ancestor detection; turns out that with UNION instead of UNION ALL we don't cull duplicates, meaning every time we would merge it'd crawl the entire history again 🙃 .

It's unintuitive, because you'd think UNION ALL is correct since the root causal shouldn't ever appear in the recursive tail, but it appears that's just not how UNIONs work in a WITH RECURSIVE CTE 🤷🏼‍♂️

Should speed up merges since this affects lca, but we can also make lca much faster, split that off into its own PR since it's a bigger change that I don't have time to test thoroughly right now: #4754

Implementation notes

UNION ALL -> UNION;
speeds this up by infinity percent (I never waited it to finish before, now it finishes instantly).

Test coverage

Did some sqlite tests and it should work.

Loose ends

While digging around I noticed that in https://github.com/unisonweb/unison/blob/trunk/parser-typechecker/src/Unison/Codebase/Causal.hs there are many functions which are computing predecessors and 'before' checks on in-memory haskell objects, these would be better on memory and probably much faster if they just used SQLite directly. Probably something for @mitchellwrosen and @tstat to look at as part of the merge rewrite 😄

See #4754

[aryairani]

Just curious if we have any existing / regression tests that exercise this?