This makes more sense as all the required information is now available
on `RoomMember`. We also don't have to handle the case of the missing
member since now you have to actually get a `RoomMember` before you can
ask for their name.
The new algorithm is simpler. Instead of tracking a list of
disambiguated display names in `Room`, we instead track the display name
ambiguity status in `RoomMember`. This allows a client to generate the
correct name for a member using solely the information available in
`RoomMember`.
The disambiguation algorithm itself now only calculates the set of members
whose ambiguity status had changed instead of producing disambiguated
display names for everyone affected. This is called on each room entry
(join or invite), room entry and profile change, and the updates are
propagated to the affected `RoomMember`s.
The `update_profile` method cannot live in `RoomMember` since that
operation needs information which only exists in `Room` (for instance,
it needs other members in order to perform display name disambiguation).
Leaving other mutating methods on `RoomMember` (like `update_power` and
`update_presence`) then seemed illogical so they were all moved into
`Room`.
In addition, a small refactoring was done to remove
`did_update_presence` and `update_presence` since their existence
doesn't make much sense anymore and it saves us from repeating work.
Their function is now done in `receive_presence_event`.
Also, several docstrings were corrected and reworded.
After discussing with poljar, we concluded we don't actually need to
tracking membership state, since we won't be tracking users that
left (banned, kicked, disinvited).
The only thing we need to keep track of is the difference between joined
and invited users which will be dealt with in a separate commit.
The client objects in the sdk accepted an optional session argument at
creation time. If provided this would restore the client into a logged
in state.
Since we need to restore the client state and encryption state at some
point it makes sense to do it when the client transitions into a logged
in state. At the same time we would like to avoid the client creation to
be async.
This introduces a restore_login() method which can be called instead of
the login() method to restore a session.
