BREAKING: implement Native OIDC as per MSC 3861

[TheOneWithTheBraid]

BREAKING: changes to the database API to better reflect the OIDC state

Work in progress. This implementation is based on the draft of native OIDC I implemented in < polycule >. It can be found here. Unlike in my initial draft, this implementation of course does not rely on any Flutter package but ships a minimal OIDC state machine relying on the matrix client to provide the native callback result via a Completer.

This implementation does not aim to comply to the full OIDC standard but only the subset required as per the MSCs stated below.

Roadmap:

• initial viable implementation
• migrate the < polycule > implementation to this OIDC stack
• excessive testing
• figure out a test concept

Implements:

• MSC 3861 - Next-generation auth for Matrix, based on OAuth 2.0/OIDC
  • MSC 1597 - Better spec for matrix identifiers
  • MSC 2964 - Usage of OAuth 2.0 authorization code grant and refresh token grant
  • MSC 2965 - OAuth 2.0 Authorization Server Metadata discovery
  • MSC 2966 - Usage of OAuth 2.0 Dynamic Client Registration in Matrix
  • MSC 2967 - API scopes
  • MSC 3824 - OIDC aware clients
  • MSC 4191 - Account management deep-linking

[TheOneWithTheBraid]

A comment on the changes to the database API:

I initially intended to just keep all OIDC-related state (device ID, OAuth2.0 client ID, auth metadata) in memory until the OIDC flow completes. I sadly figured out the Dart process might get killed by the platform for battery optimization. In order to complete the flow after the main process was killed, I decided to store the OAuth2 client ID and the homeserver's auth metadata in the database as well as to split the device ID from the remaining client store since now the device ID is present a long time before the rest of the account is available.

Even though I so far already implemented the database API changes with this in mind, there is no way to resume an OIDC flow from a new thread yet.

[TheOneWithTheBraid]

Review notice: So far, the default behavior of the updated Client.getWellknown is to only check the brand new /auth_metadata endpoint. This might require Synapse nightly builds to work. Client developers however are free to use the previous revision of the MSC suggesting to use the /auth_issuer endpoint or the .well-known entry containing the org.matrix.msc2965.authentication field. All three possible implementations are supported in this PR. Since the default is definitely going to be the new /auth_metadata, the implementation already suggests this at this point.