External OAuth provider compatibility

[pohlm01]

#77 added support for an external OAuth provider. At the moment, we require the external provider to send the roles in our proprietary roles format, see example below.

{
  "exp": 1734525218,
  "nbf": 1731933218,
  "sub": "ven_client",
  "roles": [
    {
      "role": "VEN",
      "id": "ven-1"
    },
    {
      "role": "VenManager"
    }
  ]
}

For this issue, we have to investigate how the OpenADR specification defines the existing roles, and should probably introduce a compatibility layer in the authentication procedure of the VTN. For example, if a user has the OpenADR roles read_all, write_programs, and write_events, we would probably need to map this to the AnyBusinessUser in our internal authentication mechanism.

Additionally, we should document how our authentication system works and how to make use of the fine-grained access control that we support with our internal roles.

[pohlm01]

The first step will be to implement the following mapping:

OAuth2 scopes	Internal Role
read_all & write_programs & write_events	AnyBusiness
read_all & write_reports	Ven("anonymous")
read_all & write_vens	VenManager

Individual scopes will not be supported in this first approach. For example, if the OAuth server returns only the write_programs roles, the token would not validate for any route.

If the token contains scopes to match multiple roles, all of them will be assigned. For example, if the scopes are read_all & write_vens & write_reports, the roles Ven("anonymous") and VenManager will be granted.

For now, there is no support for fine-grained access control based on IDs. This will be added later.