Cache bridge's own state events

[AndrewFerr]

When the bridge sets a room state event (namely a connection config), the bridge waits to get that state event back from the homeserver before updating in-memory structures. This is not only redundant, but means that any reads of room state (or anything related to it) may be stale until the bridge receives an echo of that state from the HS.

It would be nice if any call to the CS API endpoint for sending a state event (i.e. setStateEvent) would be replaced by a wrapper that would also update whatever objects in memory depend on that state (like the state field of connections). This would also permit the bridge to ignore any state events sent by the bridge itself, as they should already have been processed by the time they were sent. The mautrix suite uses an approach like this & it's rather convenient.

[bkil]

Related #739

Note that CS API calls may actually fail with HTTP 4xx & 5xx during submission (if you don't have sufficient permissions or for any other reason). This could happen in case of federation lag as well for example when permissions are edited in a race or any future hookshot/Synapse bug that causes delays or failure in processing events. Blindly assumed that whatever event we send to the HS will be accepted goes against building an architecture with defense in depth.