Query the primary feed in the background to preload the activities so they can be shown instantly when the user navigates to the feed page

[mayel]

Still to-do (eg. broken as a result of this refactor)

• [ ] use 'before' pagination to check for any new items when one clicks on 'feed' in nav
• [ ] show feed filters
• [ ] show nav links or tabs for specific feeds (eg. local/fediverse) and/or filter presets (eg. publications/links/pictures/videos/audio/etc)
• [ ] modals in feed activities (when in myfeed) not working - prob is just matter of using the right modal id
• [ ] sometimes when going back from feed to something else it remains an empty page (or feed does not render)
• [ ] lots of LV JS warnings (eg. duplicate ids)
• [ ] actions not appearing in feed (prob because of previous point)
• [ ] url not updated when navigating to feed
• [ ] Feed link in sidebar not highlighted when the feed view is active

Stretch goals

• [ ] use preview content for user profile like we do for post
• [x] show an about tab on profile by default
• [ ] apply feed filters (with tabs just being presets), see https://github.com/bonfire-networks/bonfire-app/issues/900
• [ ] preload profile feed in background so it's ready when you click on feed tab (but what about other tabs like posts, etc?)

---

The goal is to fetch and cache the activities in a separate elixir process as soon as the user is logged in, to reduce the loading time when showing the feed.

Implementation details

After considering and prototyping several different approaches, it seems like we may have ended up with the most high level optimisation possible (compared to caching DB queries or any steps in between):

Now when signed in to Bonfire, no matter what page you're on you can click to view the feed and it appears instantly (it is already loaded in the background and rendered in a hidden div).

In this way every time you view the feed we avoid using extra resources and time for:

• DB queries
• preloads and preparing of the data
• rendering on server
• diffing on server
• network usage / bandwidth
• diffing on client
• browser rendering

Of course it comes at the cost (especially when a user doesn't end up viewing their feed) of using extra:

• queries/processing/diffing/bandwidth/etc loading the feed for every logged in user
• user's browser CPU/RAM to render and keep it in DOM the whole time

And it requires that we fix and extensively test PubSub (see #839) to make new activities appear at top of the feed since user is not reloading it (and it would be even more of a resource waste to simply reload it every minute or whatever)