[MBL-2811] Only trigger new fetch if the relevant count changes

[ifosli]

📲 What

Currently, we re-fetch backed projects (or starred projects; whichever is currently open) if we notice that the count for either changes. This updates that check to only look at the relevant count (and adds tests).

🤔 Why

There's two things going on here that don't play nicely together.

1. If there's a fetch in progress and that fetch gets interrupted, the UIRefreshControl hides. I wasn't able to figure out why. It does look like our current setup (UITableViewController that's embedded in a different view) tends to have pretty fragile UIRefreshControl, and the fact that this view is old enough to be all storyboards did not help me personally debug it.
2. The saved/starred project count returned by our usual user fetch and the graphQL version are inconsistent, at least on my account. This means that every time the profile page first loads, it'll start fetching backed projects, the graphQL user fetch will return and update the current user, and then it'll cancel and restart the backed projects fetch. I'm not sure why the counts are inconsistent...

So, because we were re-fetching backed projects anytime the saved projects count changed and this count usually changed while the profile page was in the middle of doing its initial page, we got into a weird state where the fetch re-triggered and the refresh spinner disappeared. Switching to only using the relevant count doesn't fix either of the underlying issues, but it does mostly mitigate this bug.

Remaining issues

Loading behavior on the profile page is still not perfect. Here's some related problems I saw/have seen that I'm not fixing as part of this bug:

1. It's still possible for the spinner to disappear when the profile page is loaded. This can happens if you kill and restart the app right after backing a project. I don't expect this to occur frequently, but if it does, we can explore either adding a debounce before starting the fetch or getting rid of the "count changed so therefore refresh" trigger entirely (which would get rid or significantly change the behavior of automatic refresh).
2. The loading spinner only shows (for me) on the initial fetch. We re-fetch projects when the backed projects count changes (ex if a user backs a project and then navigates to the profile page). In this case, the fetch is fairly invisible to users (the loading spinner exists, but it's scrolled off screen). We could probably fix this by adding a scroll to top, but I hesitate to make them lose their position on the page.
3. Fetching the next page of results still doesn't have a spinner. This has never had a spinner, so it's more of a feature request than anything else. It wasn't so noticeable when we fetched projects through v1, since the fetch was faster, but now it's annoying. However, the UIRefreshControl is not the right solution for a next page loading spinner, so this is something we should prioritize separately.

👀 See

Jira

Before 🐛	After 🦋

✅ Acceptance criteria

• Loading spinner generally shows when the profile page first loads backed projects

[stevestreza-ksr]

Doubt it'd come up in real world use but could be cool to listen for Notiication.Name.ksr_environmentChanged and include that in the reactive chain as well

[amy-at-kickstarter]

As a side note, would it also help this issue if we chucked in a debounce here?

[ifosli]

Somehow, adding a debounce causes the loading spinner to hide... 😅 That's one of the reasons I think the next step is to rewrite this entire screen if this solution ends up not being good enough.

Re: listening for ksr_environmentChanged - Hmm, that's an interesting thought. I tested this in case there was something I'd missed and it doesn't look like changing the environment is something that's currently unhandled. (This view controller is only going to show when there is a logged in user, since it's embedded in the main backer dashboard view controller.)