ensure that lix works with an inlang project with 250.000 variants

[samuelstroschein]

Context

MESDK-137

• 250k messages * 1 variant = 250k variants
• initial load less than 10 seconds
• in-app CRUD on messages takes less than 100ms

Proposal

test if lix can handle this. if not, evaluate if the optimization would require breaking changes in lix. if breaking changes are required, do them now. else, we can optimize lix in the future.

[samuelstroschein]

We need to add a test for changes too. Prob saying something along the lines of each entity has 10 (?) changes to test scalability of lix.

250k variants * 10 changes each = 2.5 million changes

[samuelstroschein]

if we save changes in lix directly, avoiding diffing, no performance issues should arise because it's… just sqlite. The differ is the expensive operation.

the inlang sdk can write directly to the lix database. No need to diff :)