Implement MessageList using `transition` API

[AlexShukel]

Is your feature request related to a problem? Please describe.
Current implementation of MessageList uses local state of messages, which is used to render items in EndlessList. However, the state of messages array can be stored in state management library on top of MessageList, so this local state becomes unnecessary duplication. It would be nice to have such API that will give the possibility to store all messages only in one place, for example, in state management library.

Now useMessages hook is responsible for:

• Behavior when scroll top or bottom is reached. Now it fetches messages and merges them with previous array (using useBoundedArray)
• Scrolling to bottom on mount (if there was no initial search)
• Handling incoming / outcoming message and pushing it in the rendered array of messages
• Search behavior: initial search rendering, handling of received, next and previous search results.

If the state of rendered items moves outside MessageList, then we need to provide an API to update state.

Describe the solution you'd like
Example with use of react-suspended-query: https://codesandbox.io/s/endless-list-suspense-kfgkh1?file=/src/EndlessList.tsx
In this example the main point is that we need to change the state of query parameters with startTransition, and then this change will cause react-suspended-query to throw a Promise. When promise is pending, React will render previous list. And after promise is resolved, new array renders.

However, this is only one of many patterns of state management, so rchat should not make any transitions or something similar.

The API of MessageList should notify that bounds of rendered messages has been changed. To take the most general case, it is possible to notify about changed bounds in the following way: send how many messages to render before ITEM and how many messages to render after ITEM. This approach is suitable both for scrolling top / bottom and for searching messages.

[AlexShukel]

Problem with absolute position parameter
If we want to make fetching messages to depend on state of paging (example https://codesandbox.io/s/endless-list-suspense-kfgkh1?file=/src/EndlessList.tsx), then we should track absolute position of currently visible items in the list. In this way if user's scroll reaches bottom, then the absolute position (paging) will change, for example, from [0; 20] to [0; 40]. And there will be additional transfer of data that has been already fetched, that is interval [0; 20]. So, the optimal way would be to fetch [20; 40] and concatenate this peace with previous.

[AlexShukel]

What if there is no possibility to track currently visible messages by paging?

There is the following case: when we want to search messages in an EndlessList, we call particular service to get the search results depending on search query. Then, we need to show the first item from search results in the middle of a screen. So, we have only information about particular item that must be rendered in the middle, and we have no access to the absolute position of this item in DB.

Given an item, we need to fetch some constant number of items before and after this item in order to render whole screen with our first search result item in the center. So, we need to somehow design a query useMessages that will always give the recent messages to be rendered on the screen.

Hook useMessages will depend on:

1. Room id
2. Anchor item (paging is not suitable)
3. Direction (begin / end)
4. Additional size (number of items to be additionally fetched on top / bottom reached)

[AlexShukel]

2 approaches to leverage the local state of messages

1. Fetch new messages imperatively and merge them with previous messages (for example, using react-query mutations).
2. Change the state of local parameters that trigger suspense.

Second approach has more advantages, because in such a way we can easily show loading indicator (with react transition API) or handle errors with react error boundaries. Also second approach has a possibility to cache messages.

However, there is a problem if we want to cache messages, as there will occur duplicate data between different cache entries when user scrolls top / bottom and searches a message.