[augustuswm]

Large PR that will bump to us to v0.6.0. There are a few major points being addressed in this version.

Unintended breaking changes:

• Known issues fixed. Looking for more.

Major changes

1. Direct permissions on mappers
   These were a mistake to add originally and this version officially drops them. Mappers still exist and are first class way of doing jit provisioning, but consumers may now only apply groups to users as a result of a comparison. This refactor changed the shape of the mapper engine and will require host applications to update.

• Any existing V1 mapper stored in the database is still able to be read and used, but only the group assignments from it will be added, any direct permission assignments are dropped.
• Preset mappers in V1 format will fail upon startup and will need to be updated.

3. Removing blanket permission changes
   Permissions are now added and removed one at a time. Bulk assignment and removal of permissions are painful to represent internally, and quite unsafe for callers as callers have to provide the full set on every call. In practice it is much easier to only support add and remove.

4. Endpoint removal
   A few endpoints were removed:

Endpoint	Reason
POST /api-user	Non-provider backed users are not supported, and this endpoint is a relic of a previous design.
POST /api-user/{user_id}	User permissions and group membership are now managed through dedicated add/remove endpoints.
PUT /group/{group_id}	Groups cannot be renamed. Allowing renames is fundamentally unsound in the context of JIT provisioning based on group names.

5. OAuth error response format
   Multiple OAuth endpoints had their error responses fixed so that we are closer to complying with RFC 6749 §5.2 .

6. Storage model changes
   There have been changes to some of the user and group structures. Anything that carries permissions now carries a generation number so that we can detect collisions between racing requests to add or remove permissions. A failure to win a race now results in a 409 CONFLICT response.

7. OAuth clients as service accounts
   An OAuth client can now authenticate as itself via a client credentials flow. This is a new pathway to be able to better support server to server communication. The goal here is to continue keeping with short lived credentials, but we do not want them assigned to users. The focus here is RFC 7523 JWT based client credentials, and we have no intent to implement a shared secret option. All clients are allowed to be used as a service account. We may want to restrict this, but I'm not sure yet what that looks like (maybe a new permission).