Changes to m.room.power_levels events are supposed to be handled at a high
priority; however a typo meant that the relevant bit of code was never
executed, so they were handled just like any other state change - which meant
that a bad person could cause room state changes by forking the graph from a
point in history when they were allowed to do so.

Merge pull request #367 from matrix-org/daniel/readafterleave

Tweak guest access permissions

Merge pull request #360 from matrix-org/daniel/guestroominitialsync

Allow guest access to room initialSync

 * Allow world_readable rooms to be read by guests who have joined and
   left
 * Allow regular users to access world_readable rooms

Allow guests to set their display names

Depends: https://github.com/matrix-org/synapse/pull/363
Tests in https://github.com/matrix-org/sytest/pull/66

Depends: https://github.com/matrix-org/synapse/pull/363
Tests in https://github.com/matrix-org/sytest/pull/66

Consider joined guest users as joined users

Otherwise they're inconveniently allowed to write events to the room
but not to read them from the room.

Otherwise they're inconveniently allowed to write events to the room
but not to read them from the room.

Fix race creating directories

Allow guests to access room context API

Incremental background updates for db indexes

Return world_readable and guest_can_join in /publicRooms

Allow guest users to join and message rooms

Get display name from identity server, not client

Don't fiddle with results returned by event sources

Overwriting hashes returned by other methods is poor form.

Fixes: SYN-516

The progress for each background update is stored as a JSON blob in the
database. Each background update is broken up into separate batches.
The batch size is automatically tuned to try avoid blocking single
threaded databases for too long.

... merely because I was trying to figure out how it worked, and couldn't.

SYN-513: Include updates for rooms that have had all their tags deleted

Conflicts:
	synapse/storage/tags.py