Support federation requests in ruma-client

[jplatte]

Currently the API in ruma-client is only usable for client-server endpoints.

We should have a FederationClient (and maybe later an appservice one too) for non-CS requests.

[iinuwa]

Might this also require changes from #528?

[jplatte]

Since ruma-client just sends requests and receives responses, no. Those changes would be for the side receiving the requests (and generating responses).

[ShadowJonathan]

I think #894 could help with some version incompatibilities, should they rise up in the future.

[jplatte]

Deferring this. I think in any case the Client only makes sense for the C2S API, if we want to support other APIs we may need a separate type like FederationClient.

[ShadowJonathan]

👍 to a seperate FederationClient, I had some doubts with merging those two in the first place.

[jplatte]

Updated the issue description to describe separate client types. That makes this no longer a breaking change.

[ShadowJonathan]

After discussing #894 a bit in the spec room, i think that the federation client needs to handle versioning differently than the normal client, as the primary intention for the federation api is to handle them in a fallback manner, retrying them with another version if the newest one isnt supported.

To make this easier, we could offer objects ("dialers") which could try each of these endpoints in-turn, returning control briefly to the callee before trying a new one, to either bail or alter the input. (Maybe something like ControlFlow could be used)

This could incorporate compat and future (see MSC3643) fallback mechanics, and allow server code to decide what to do based off of that.

Additionally, we could allow the callee to retrieve which endpoint the dialer had chosen in the end, to allow a subsequent call to quickly use that endpoint, before falling back to the normal sequence if it fails.