Previously, a transaction panicking in the handle() call would cause the
transaction to be indefinitely logged as "running" in the transaction
handler. This means subsequent transactions from the sending server
would be met with the "You're still sending me a txn!" 429 response,
forever, effectively causing defederation between the two servers, until
continuwuity is fully restarted.
I could just fix the known panics in the handle function and internal
calls, however there's so many subsystems that could reasonably panic
that it is just better to have a safer approach and ensure that the
handle call is infallible.
On room creation, A list of initial state events may be provided that
should be submitted to the room after creation. These events
should be treated as any other state event and submitted to
the same checks.
With this change, state events submitted on room creation will be
submitted through the same helper as those through the usual endpoint.
The submission helper is moved to the timeline service to make it
available everywhere. This will be useful for implementing MSC4140
(issue #903).
The current `request_ip_source` setting only allows a single option.
While it does fall back to the peer IP if the header is missing as of !2003,
which likely covers a lot of regular use, only allowing a single option limits
the deployment options available to more advanced deployments.
Setups where internal and external traffic use different reverse proxies will
end up with the wrong IP and the implicitness of the fallback allows for
situations where the used IP is not the IP expected.
By introducing a setting that allows multiple options to be set,
this limitation is resolved and it becomes possible to have client IP resolution
behind different reverse proxies and also making it possible to decide if and/or
what the fallback should be.
If set, options are evaluated in order. If all fail, the request fails.
Jade