Optimize Pagination by Filtering Beacon Events

I am encountering performance issues during pagination with the /messages API in rooms, due to processing a large number of org.matrix.msc3489.beacon events. While encrypted rooms still need to process each beacon event, I propose using the not_types RoomEventFilter to speed up pagination in non-encrypted rooms.

Additionally, I'm looking for guidance on optimizing live location sharing to improve its scalability within the SDK. Any insights or alternative strategies would be greatly appreciated.

Example timeline, the spec needs to only render the two m.text items in the timeline:

m.text
org.matrix.msc3489.beacon
org.matrix.msc3489.beacon
...2,000 more org.matrix.msc3489.beacon
m.text

Proposed solutions:

1. Modify the paginate function to accept an optional RoomEventFilter, allowing clients to specify a custom filter.

async fn paginate(
        &self,
        dir: Direction,
        num_events: UInt,
        room_event_filter: Option<RoomEventFilter>,
    ) 

2. Automatically filter by default on MessageOptions

impl MessagesOptions {
    /// Creates `MessagesOptions` with the given direction.
    ///
    /// All other parameters will be defaulted.
    pub fn new(dir: Direction) -> Self {
        Self { from: None, to: None, dir, limit: uint!(10), filter: assign!(RoomEventFilter::default(), {
                not_types: Some(vec![MessageLikeEvent::Beacon.to_string()])
            }) }
    }

Start with crates/matrix-sdk/src/event_cache/paginator.rs at paginate and crates/matrix-sdk/src/room/messages.rs around MessagesOptions::new. Read how RoomEventFilter is passed to pagination and how encrypted versus non-encrypted rooms process beacon events. Done should establish an agreed filtering approach and verify that /messages pagination avoids unnecessary beacon processing without breaking encrypted-room handling.