Fix `post_view.prefetch_cursor_before_data`

[dessalines]

As part of #5429 , I removed the recursion in post_view.list calling itself, but my corrections are wrong.

My questions are:

• Why is this necessary? Is it only used for backwards pagination for Subscribed?
• Are there better ways we should be handling subscribed? I have some ideas here.

---

not correct, because it has to use the same sort as the normal query for correct results, and it has to use the same filters for full optimization

probably best to:

• move everything currently in list to a new helper function like list_inner which takes additional parameters cursor_before_data: Option<Post>, community_id_for_prefetch: Option<CommunityId>
• remove cursor_before_data and community_id_just_for_prefetch from PostQuery
• make list just be a wrapper function that does mostly the same thing as the prefetch_cursor_before_data function here but uses 2 calls to list_inner (first one is for getting the upper bound)
• also in the list wrapper function, add back the condition self.listing_type == Some(ListingType::Subscribed) and use if let to replace the self.local_user.is_some() condition, so getting an upper bound is only done for subscribed view

Originally posted by @dullbananas in #5429 (comment)

[dullbananas]

It's for both forward and backward pagination. It's to solve this problem: #2877 (comment)

[dessalines]

I've added this to the 1.0 milestone to make sure it gets fixed before then.

See also @phiresky 's comment here for why this is necessary: #5555 (comment)