The current implementation uses number of invited and joined members for
"and {} others" message. This assigns rooms with 5 members the name "a,
b, c, and 5 others" suggesting 8 room members. The correct message is
"a, b, c, and 2 others". To get this, subtract number of heroes from
invited and joined member count.
Step 3.ii of the naming algorithm[0] confirms using a remaining users
count in the name.
[0] https://matrix.org/docs/spec/client_server/latest#calculating-the-display-name-for-a-room
Split `calculate_room_name()` into a high-level function using Matrix
data types and low-level function containing the core logic using plain
Rust data types. Since the low-level function uses simple data types,
unit testing becomes easier.
Step 3.ii of the name calculation algorithm[0] specifies the conditional
as `heroes < invited + joined - 1 AND invited + joined > 1`. However,
current implementation uses `invited + joined - 1 > 1` in the
conditional, which can trigger the conditional if the user is alone.
Correct this by using two variables representing `invited + joined` and
`invited_joined - 1` and updating the conditional. `invited + joined` is
kept as a variable since step 3.iii uses it for its conditional.
[0] https://matrix.org/docs/spec/client_server/latest#calculating-the-display-name-for-a-room
Our main methods to get members nowadays ensure that the member list is
synchronized with the server. This is nice and convenient but might not
be desirable for a couple of reasons.
Firstly it might be costly to fetch all members at once depending on
what the client is doing and the number of rooms and secondly some
clients might have a hybrid setup where not everything is running on a
tokio thread, sending out requests is only possible on a tokio thread.
This patch changes the way we store and load the majority of events that
are in the state store. This is done so custom fields in the event
aren't lost since a deserialize/serialize cycle removes all the unknown
fields from the event.
