* initial support for block/mute
* hide blocked + muted content everywhere
* add info message for blocked/muted characteristics
* sort blocked list by most recent block first
* add 'blocked' message on channel page for channels that you have blocked
* cleanup
* delete unused files
* always pass mute/block list to claim_search on homepage
* PR cleanup
## Issue
5090: When sorting channels, switching between Trending/Top/New returns viewer to the top of the page
## Approach
- Add an optional parameter to `ClaimListDiscover/Header` to add an additional anchor ID when building a new search URL.
- Clients then add the anchor ID on the desired location.
- The code that handles the scrolling then checks if the `location` contains an anchor hash. If it does, we'll scroll to that element; else, the existing behavior will be used.
## Issues
(1) 4783: New search query does not reset to the top
(2) The current way that Tag Search resets the position can be overridden by the AppRouter's call.
## Approach
Listen to `search` changes as well. This basically covers any search param changes.
Components should probably not call `window.scrollTo` directly as the AppRouter's call might override it.
## Issue
4609: If claim search on latter page fails, don't clear out all previous data
## Note
This requires an accompanying change in `lbry-redux` to mark `claimSearchResultLastPageReached` during timeout and to not purge past results.
## Change
The previous flow was: increment the page, and expect the next render to either be 0 (timeout + purge) or fill in at least 1 new item.
Since it is now possible for no results to be returned for the new page (due to timeout + no purging), the code continues to make another query. This commit stops the perpetual querying.
## Test Case:
1. https://lbry.tv/$/discover?t=imherelbry&content=video&order=top&fresh=year
2. Scroll down a few pages until it timeout happens. Past results are gone.
## Issue
Fixes 2675 `Claim search with exactly 20 results keep fetching next page`
## Changes
Use `claimSearchResultLastPageReached` (I didn't know it existed back then).
The unnecessary "loading" refresh will still happen one time, but at least now it doesn't happen every time we scroll to the bottom (and incorrectly incrementing 'page').
This is a follow-up on PR-4392.
## Issue:
The previous PR covered "pop from within the same page but with different query/order", but missed "pop after entering a claim".
1. Click `Your Tags`.
2. Set order to `New`.
3. Restart app or reload (crucial step)
4. Click `Your Tags`.
5. Click any claim.
6. `Back`. The order incorrectly resets to `Trending` -- it should stay at `New`.
## Fixes:
3071: "Infinite scroll stops working when navigating to file page / back"
## The Issue:
In the POP operation, the `page` value is back to 1 due to the initializer `useState(1)`. If the results cache already contained more than 1 page's worth, then the rest of the logic thinks there's nothing to do.
## The Fix:
Previous fixes to Inf-Scroll added a "page correction" code to handle the mismatch. This fix simply adds this scenario to the list of scenarios to perform the correction.
--- Issues:
(1) #-2669: Page does not restore to top when navigating new tags.
(2) "Encountered children with the same key" error (duplicate entries shown).
https://github.com/lbryio/lbry-desktop/issues/4367#issuecomment-645449206
--- Changes:
(1) Ignore the history if it's a new query (i.e. explicitly clicked). The BACK history will still behave as normal (doesn't reset to top).
(2) Previously, the `page` variable will continue to increment as you scroll and stay within the page (e.g. Trending vs New, or clicked another Tag). As you move between queries, we hit a scenario where `page` is significantly under or over the latest retrieved `claimSearchResult.length`. This messes up the rest of the code.
Fix by correcting the value of `page` according to the current `claimSearchResult.length` when necessary.
--- The bad scenario:
A less popular tag like 'kanji' yields only 23 results today. The code continues to increase the page count. We'll either see some blank page glitches at the bottom, or repeated entries being shown.
--- The fix:
Assume that an unfilled page means "no more results" and stop incrementing the page. This seems true based on empirical evidence.
