native: increase channel scroll position stability when loading to anchor

[davidisaaclee]

Description	Before	After
Simulated load around anchor – here's the worst case I could find for the "before" case - most of the time it's relatively stable with a small blip in position.	before-load-around-worstcase.mp4	after-load-around.mp4
Load "blitz" – load posts out of order, with anchor not in first page. This is an unlikely scenario, but illustrates what things look like in a worst-case, possibly buggy release.	before-load-blitz.mp4	after-load-blitz.mp4
Load newer posts while locked to anchor – after loading channel with anchor locked to top, I pressed the Load newer button that adds posts to the "new" end of the timeline	before-loading-newer-posts.mp4	after-loading-newer-posts.mp4

• [extra] Replace all Math.random with a seeded random in fakeData.ts – this ensures that Cosmos fixtures always look the same (unless you change the seed).
• Added two Channel fixtures: one that simply loads a chat with an unread anchor, and one that has a toolbar for interactively loading posts in different ways.
• Reorganization of anchor scroll lock code – hidden in this reorg are the following key changes:
  • We previously attempted to scroll to anchor whenever any list item got laid out (and we believed we had an anchorIndex) – removed attempts to scroll when non-anchor list items are laid out. (My guess is that this used to be the case to emulate maintainVisibleContentPosition as list items moved the anchor around, but we can rely on mvcp now.)
  • Previously, when a scroll-to-anchor failed, we scrolled to a "best guess" of the anchor and rested (probably relying on the "did layout" scroll attempt to fix stuff). Now, on a scroll-to-anchor failure, we mark ourselves as explicitly needsScrollToAnchor = true, and wait for an anchor layout to trigger a scroll.

I kept the existing code for autoscrollToTopThreshold, but I believe that that feature is broken in the build of RN that we are using – we should apply facebook/react-native#38245 (tested in a quick-n-dirty patch and appears to work)

Content is still shifting a little bit as things load in: I believe this is due to images in messages resizing themselves, and thus their ChatMessage containers.

I've logged into this client on my live ship and browsed around to channels with lots of unreads, and some with no unreads – things seem fairly stable. (Did the same with current release client and it is less scroll-stable.)

[galenwp]

Heroic

[latter-bolden]

This is much easier to read through! Appreciate the copious amount of comments <3

The posts disappearing during search scrollback feels like a regression we should address before merging, but otherwise this feels like a much better base to build off of.

[davidisaaclee]

In the before case, I didn't record jumping to the selection anchor from search page – it anchored correctly to the item, but only after scroll position jumped up and down a few times.

Current Testflight client	5817765
before-dagoth.mov	after-dagoth.mp4

There are still some white flashes at 5817765, which I tried to capture but could not – in any case, I think the flashes are much briefer.

---

starting at 6765d3f...

• Main change was reducing how many posts we load on each page – we still load enough to fill a page+, and I increased the threshold before we start loading more posts to keep things smooth.
• I removed a demo seed on the seeded RNG and didn't realize that not providing a seed made the RNG "unseeded", causing a different output on each run – seeded with empty string to pin.
• Stabilized identities of the simple deps to listRenderItem
• listRenderItem relies on each post's neighbors to draw dividers etc – to avoid resetting the callback every time posts changes, I derived postsWithNeighborsin a different useMemo. I don't know if this has an effect yet (depends on how much memoization FlatList does internally), but it sets us up for increased memoization.

[latter-bolden]

Changes make sense to me. Likewise curious if you'd have feedback on the modified post fetch count @dnbrwstr.

Excellent work on the fixes! Was feeling really good on my dev build.