sync: better /changes handling

[latter-bolden]

Summary

Modifies the /changes endpoint codepath to

a) let the resulting DB updates propagate more quickly
b) provide a stronger guarantee that result Posts with higher sequence nums make their way to existing channel queries

Fixes TLON-5331
Fixes TLON-5332

Changes

• in syncStart, move syncSince ahead of the longer High Priority batchEffects
• when Posts flow into the DB via /changes and /heads, ensure they're appended to useChannelPosts results using the same mechanism as subscription updates
• add comprehensive timing telemetry for open to ChatList and tap Push Notification

How did I test?

iOS/Android preview builds

Risks and impact

• Safe to rollback without consulting PR author? Yes
• Affects important code area:
  • Message sync

[dnbrwstr]

Fwiw, tested this against the stale-posts-on-boot-from-notification issue. In my testing today, both this branch and develop seemed to have the same behavior: new messages would pop in after 7-8 seconds.

[latter-bolden]

develop seemed to have the same behavior: new messages would pop in after 7-8 seconds

we chatted out of band, but the slow timing when opening from cold start seems to be the syncSince call having its effects batched with the rest of syncStart high priority. That operation consistently takes right around 7-8 seconds.

Tethering useChannelPosts to a latestSeqNum should defensively cover a broader range of cases than just returning from a force quit.

[dnbrwstr]

Lgtm!

[linear]

TLON-5331 channels: showing stale data and not live updating

TLON-5332 sync: initial sync returning from background very slow

[latter-bolden]

I'm still having trouble getting this to go green for the e2e tests

• All failing tests succeed locally when run together using pnpm e2e:test ...files
• They still fail after commenting out the only substantive change I could see affecting things (the useChannelPost refetch)

I'm slowly rolling back (what I thought were) inconsequential changes to try and isolate the issue