Allow /createRoom to be run against event creator

[erikjohnston]

Currently it has to point at master, purely because store_room calls self._public_room_id_gen.get_next(). We should try and figure out a way that we can run /createRoom without interacting with master if possible.

[anoadragon453]

Would this involve modifying/splitting out self._public_room_id_gen into a MultiWriterIdGenerator instance, similar to what was done for presence's ID generator here?

[anoadragon453]

Would this involve modifying/splitting out self._public_room_id_gen into a MultiWriterIdGenerator instance, similar to what was done for presence's ID generator here?

I believe so. One needs to:

1. Convert self._public_room_id_gen to a MultiWriterIdGenerator such that it can be incremented by more than one process.
2. Move the store_room storage method to RoomWorkerStore.

With that, we could also explore moving room upgrade tasks to workers, as they also rely on being able to create a room.

[anoadragon453]

#9044 is another good example of a PR moving a StreamIdGenerator / SlavedIdTracker pair to a MultiWriterIdGenerator.

However in the process of investigating what would be involved, @erikjohnston noticed that this stream doesn't actually seem to be utilised anywhere anymore. It likely stemmed from the days of when we used to paginate the public rooms list with stream IDs, instead of an arbitrary pagination today - which we have today.

As such, the solution here is simply to just remove public_room_list_stream, rather than needing to convert it. That will then unblock moving /createRoom off of the main process.

As with all potentially risky database changes, the plan is to:

1. Remove reading and writing to public_room_list_stream, but keep the table around just in case.
2. Ship a release of Synapse and let that change sit for a bit. Move /createRoom off the main process at the same time.
3. Create a migration to remove the table and its contents.
4. Ship another release.

[anoadragon453]

Fixed by #10564.