I tried keeping the mocking but it would take too much
boilerplate code to make the tests work again, and even more
to write the tests for room name with lazy loading.
Just testing everything with a real implementation is not really
a unit test any more, but proved way easier.
It'll be somewhat annoying these tests will fail if there is
something wrong in roomstate (not room), but that's the trade-off
some tests for mock getMember, some for .members
if you use either in the code (as I did for room display name changes)
tests start playing and you play whack-a-mole switching between
both ways of accessing the members in a room.
lets start using one way so mocking becomes easier,
and besides, accessing an object internal members is not the best idea.
getSentinelMember now does return a member (with just the userid) when there is no corresponding member yet.
With lazy loading it's perfectly possible the member is not available, and null breaks continuation in the timeline.
When joining a room we were peeking into, we duplicated all the
state events into the timeline. Put back the old behaviour of just
setting them as state events, with copious commentary on how wrong
this seems.
* Check whether we share an e2e room with user IDs in the 'left'
field of /keys/changes: there's no guarantee we no longer share
any e2e rooms with these users
* Reset everyone's tracking status on an initial sync - just
re-fetching device lists for all users we're currently tracking
isn't good enough since room memberships may have changed.
* Fix typo in test
Mostly making tests aware of new storage format or making them
force it to be written. Also some bugfixes like we didn't json
encode some things in the localstorage store and we didn't
correctly check the promise when requesting device data saves.
When we no longer share any rooms with a given user, the server will stop
sending us updates on their device list, and will (once synapse is updated)
send us a notification of that fact via the 'left' field in the device_lists
field in /sync, or the response from /keys/changes.
There's a fuzzy line between the megolm tests and the devicelist ones, but
since I want to add more tests for devicelists, we might as well put the ones
which are definitely about devicelists in their own file
