fix: move cache invalidation to after transaction commit

[wschurman]

Why

Implementation of second idea from #76.

How

• Append bound async functions to array of fns that are executed after transaction has been committed.
• Move general entity integration tests into separate package that integrate all cache and database adapters.
• Write a test that fails with the previous implementation and passes with the new implementation (EntityCacheInconsistency-test). This test runs an update in a long-running transaction and does a single targeted load between when the cache is invalidated (in the old implementation) and when the transaction completes. With the old implementation, the cache would have been cleared before the change was visible to other machines. With the new implementation, the cache is cleared at commit time (right after commit). Technically there still could be a race if the loads of a single entity are super frequent and an update occurs but that problem can't be solved without a distributed reader-writer lock which at this point is probably overkill.

Test Plan

Run new test.

[codecov]

Codecov Report

Merging #77 into master will increase coverage by 0.12%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #77      +/-   ##
==========================================
+ Coverage   94.48%   94.61%   +0.12%     
==========================================
  Files          59       60       +1     
  Lines        1506     1522      +16     
  Branches      171      181      +10     
==========================================
+ Hits         1423     1440      +17     
+ Misses         81       80       -1     
  Partials        2        2              

Flag	Coverage Δ
#integration	94.61% <100.00%> (+0.12%)	⬆️
#unittest	94.61% <100.00%> (+0.12%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
packages/entity/src/EntityCompanionProvider.ts	100.00% <ø> (ø)
...ter-knex/src/PostgresEntityQueryContextProvider.ts	100.00% <100.00%> (ø)
...ample/src/adapters/InMemoryQueryContextProvider.ts	100.00% <100.00%> (ø)
packages/entity/src/EntityCompanion.ts	100.00% <100.00%> (ø)
...s/entity/src/EntityMutationTriggerConfiguration.ts	100.00% <100.00%> (ø)
packages/entity/src/EntityMutator.ts	98.00% <100.00%> (-0.03%)	⬇️
packages/entity/src/EntityQueryContext.ts	100.00% <100.00%> (+5.55%)	⬆️
packages/entity/src/EntityQueryContextProvider.ts	100.00% <100.00%> (ø)
packages/entity/src/ViewerScopedEntityCompanion.ts	100.00% <100.00%> (ø)
packages/entity/src/internal/EntityDataManager.ts	100.00% <100.00%> (ø)
... and 3 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 62bfd6c...133b774. Read the comment docs.

[wschurman]

One thing to figure out is if we want these invalidations to occur right before or right after the transaction commit.

[ide]

Really like the regression test.