Previously the re-invite procedure probably only worked, since the task
execution was slightly delayed (after the `MatrixChatGestaltSettings`
object was stored *and* connected to the `Gestalt` object).
But this did not work during the tests (since `huey` is configured for
immediate processing).

Thus we handle changed Matrix IDs more carefully now:

* obsolete details (e.g. invitations) get deleted before the new Matrix ID is stored
* new invitations are explicitly sent to the new Matrix ID
  (even though the data is not consistently written to the database, yet)