* Use `CryptoApi.getKeyBackupInfo` instead of deprecated `MatrixClient.getKeyBackupVersion`
* Review changes
---------
Co-authored-by: Michael Telatynski <7t3chguy@gmail.com>
* Add `asyncFilter`
* Replace `MatrixClient.isRoomEncrypted` by `MatrixClient.CryptoApi.isEncryptionEnabledInRoom` in `MemberListStore.tsx`
* Replace `MatrixClient.isRoomEncrypted` by `MatrixClient.CryptoApi.isEncryptionEnabledInRoom` in `EventIndex.tsx`
* Replace `MatrixClient.isRoomEncrypted` by `MatrixClient.CryptoApi.isEncryptionEnabledInRoom` in `SendMessageComposer.tsx`
* Replace `MatrixClient.isRoomEncrypted` by `MatrixClient.CryptoApi.isEncryptionEnabledInRoom` in `ScalarMessaging.ts`
* Replace `MatrixClient.isRoomEncrypted` by `MatrixClient.CryptoApi.isEncryptionEnabledInRoom` in `RolesRoomSettingsTab.tsx`
* Add reject doc to `asyncFilter`
* Reverse `MemberListStore.loadMembers` condition
* Remove async for `ScalarMessaging.ts`
* Display permission section only after `isEncrypted` is computed
* Display composer only after `isEncrypted` is computed
* Revert "Display composer only after `isEncrypted` is computed"
This reverts commit 4d4e0373919ad4b0e6fa53de63786c880ed6845a.
* Revert "Replace `MatrixClient.isRoomEncrypted` by `MatrixClient.CryptoApi.isEncryptionEnabledInRoom` in `SendMessageComposer.tsx`"
This reverts commit 6bf06da02ca2c0cf72f0e12a418d07f05a86da3a.
* Refactor feeding of events to widgets
This is a pure refactor with (hopefully) no behavior changes.
* Feed events to widgets as they are decrypted (even if out of order)
The code that feeds events to widgets tries to enforce that only events from the end of the timeline will be passed through. This is to prevent old, irrelevant events from being passed to widgets as the timeline is back-filled. However, since encrypted events need to be decrypted asynchronously, it's not possible to feed them to a widget in a strictly linear order without introducing some kind of blocking or unreliable delivery. This code has been dropping events when they're decrypted out of order, which we consider to be an undesirable behavior.
The solution provided here is that, to reflect the asynchronous nature of decryption, encrypted events that arrive at the end of the timeline will be fed to a widget whenever they finish decrypting, even if this means feeding them out of order. For now we're not aware of any widgets that care about knowing the exact order of events in the timeline, but if such a need reveals itself later, we can explore adding ordering information to this part of the widget API.
* Add braces to if
