Please address @ashoat suggestion before landing.

I have for questions for @kamil:

1. What is the purpose of version column?
2. Isn't the counter value extractable from the session object itself?
3. When and how is it going to be updated? Is it possible that value in the version column will go out of sync with the counter value in the session object?
4. Finally, is that going to be a problem the we don't have such counterID tracking for notifs sessions - in case it is should we implement it for notifs as well?

Rebase before landing

Update WASM

Remove unnecessary migration function and replace it with dummy lambda that is not run inside transaction.

Check CI - last results confusing

Bring lines accidentally removed during conflict resolution

1. Avoid using let instead of const.

Fix throws declaration

Avoid using let instead of const.

Remove unnecessary dispatch_semaphore_signal since it is in the finally statement.

Address Tomek suggestions

Address Tomek suggestions

Address Tomek suggestions

Address Tomek suggestions

Add a try catch to grafecully handle the case if the user doesn't open the app after upgrading it.

1. Address Kamil feedback
2. Rebase before landing

Some nits left but looks good.

Send different holder to each recipient device

Send different holder to each recipient device

Rebase before landing

Fix clang formaatting in SQLiteQueryExecutorBindings

Accepting but I am of strong opinion that it would be better to create two new structs: NonSyncedKeyserverInfo and SyncedKeyserverInfo that would look exactly the same as original KeyserverInfo. In SQLiteQueryExecutor methods we would just create instances of each class and could rely on simple SQL queries without named parameters. The code would be easier to understand and maintain. It would be two small classes doing simple logic instead of one bigger doing complex logic.

Are we sure that we will never want to inspect the content of keyserver_info values stored in keyserver_synced_data in C++? I am basically asking about the risk that we will have to manually parse JSON-strings in C++ in future.

LGTM for me but please stick to the convention to use SQLiteStatementWrapper.

Rebase before landing

Rebase before landing

Rebase before landing

Do I understand correctly that this diff makes keyserver one time keys upload match approach that is used on native - eagerly marking one time keys as published before they get uploaded to the identity?

1. Update queryNotifsUnreadCountStorage function not to rely on array ordering.
2. Rebase before landing

1. Update a comment about legacy IndexedDB key format.
2. Rebase before landing

Rebase before landing

Rebase before landing

Simplify blob client API and make it match the Android one.

Fix missing newline

Renew the code.

Those changes will be included in updated version of child differential.

Fix missing newline

Renew the code.