Add temporary UIAuth provider

[mujx]

The endpoint is undocumented and it is used temporarily instead of the UIAuth flows. It should be removed shortly after. Currently the riot client queries this endpoint, before proceeding with the actual POST login request.

The implementation is simple and self-contained so it can be removed easily in the future.

Here is the relevant issue on matrix-doc and here is what the endpoint looks like.

[jimmycuadra]

You say it will be removed in the future because of @richvdh's comment that /login should just implement interactive auth? I'm not totally clear on the distinction between:

1. How it works now
2. How it was supposed to be working
3. If there are concrete plans for it to work differently in a future version of the spec

If the answer to 3 is that yes, there are plans to change it, then it would be helpful to know how far out those changes are.

/cc @ara4n

[mujx]

From my understanding it's used to provide a list of the ways that a client can be authenticated. It's a legacy solution that should be replaced by UI Auth because they serve the same purpose.

UI Auth returns

{
  "flows": [
    { "stages": [ ... ] },
    ...
}

where this endpoint returns

{
  "flows": [
    { "type": "m.login.xxx" },
    ...
  ]
}

The changes were made so ruma can work and be compatible with the current state of riot.

[jimmycuadra]

I do remember running into this when trying out Riot (Vector at the time) against an early version of Ruma. I'm just trying to see what the best way to deal with this is. If UI auth is going to be added to the spec in an imminent new version, then we might not need to do this. The mistake here is really in Riot and Synapse because they don't follow the spec.

[jimmycuadra]

Pinging @ara4n and @richvdh again. I really don't want unspecified behavior to end up in Ruma. Advice on how to move forward on this? What's the plan for the next version of the spec?