Pending State

Having only a single path on which updated data flows in a client greatly reduces the complexity to update its UI. Naively this is possible by making a request to the homeserver and updating the UI with the response. The obvious downside to this is the delay in visual feedback, which makes the client’s UI feel sluggish.

The solution to the unresponsive UI is to hold local, *pending* state for the duration the request is in flight. This pending state can be displayed in the client until requests have been settled. The downside to this approach is its additional complexity and multiple data paths that are introduced into the application: Handling multiple requests at once, some of which might fail, while incorporating successful responses is non-trivial. This being a very general and tricky problem makes it a good candidate to be solved in the SDK.

One approach to relieve the client of handling pending state is to disguise it as real state from the server. In this scenario the SDK keeps book of the current state as sent by the server and all requests in flight. It has also to take into account the order in which requests were issued and the order in which they got completed at the homeserver. Always the most up-to-date, non-failed state is pushed to the client by the SDK. In some cases when a request fails, old state has to be restored.

*Example of updating a room name twice (source: [pending_state.drawio](https://github.com/matrix-org/matrix-rust-sdk/files/6939809/pending_state.zip))*

A practical way to achieve the described system seems to be incorporating pending state into forged SyncResponses.

### Miscellaneous Thoughts
- While in the simple case the client might be happy without knowing whether a given update came from the server or not, there should be a way to distinguish the cases for more advanced usage.
- This approach might be applicable to room state, account data and even pending message events.
- Relying on non-approved state might lead the client to issue invalid requests to the server.

The issue names no implementation files or tests. Start by tracing how the SDK builds forged SyncResponses and handles in-flight requests; done would require an agreed design covering ordering, failures, and pending room or account state.

Written by the indexing model from the issue text.