Restructure authentication policies.

[partim]

This PR restructures how authentication policies are used in Krill. It removes the use of Oso and its policy definition language and instead switches to simple, straightforward mappings between permissions, roles, and users.

The existing concept of roles is augmented to serve as the central configuration option for limiting a user’s access to certain action and resources. Roles are now user configurable via the new auth_roles configuration directive. For each role, a set of permissions has to be provided. Optionally, a list of resource handles (vulgo: CAs) can be given in which case access is limited to these resources.

The authentication providers now assign one of these roles to each logged in user.

The OpenID Connect provider now only determines claims for “id,” i.e., the user name, and the “role.” Since we replaced the previous use of JMES paths with custom functions with a more stringent model of matching and substitution, the configuration had to change in a non-compatible way, anyway, so we cleaned it up a bit and switched from a map to an array for the claims.

For the config file provider, this was already possible by adding a “role” attribute. This has now been changed into a “role” field of the user details. In order to make upgrading seamless, the “role” attribute is still accepted but a deprecation warning is logged. Since the auth_users configuration is not used for the OpenID Connect provider any more, the password_hash and salt fields of the user details are now mandatory.

Custom policies have been removed.

[partim]

At this point, I have removed the oso and jmespath crates and shifted all policy decisions into the new daemon::auth::policy module. However, the module is currently just a stub. Next we need to define the actual policy configuration and implement it.

[partim]

The auth::policy module is gone again and has been split into private auth::roles and auth::permissions modules with their types re-exported at auth.

I have also implemented the new strategy outlined in #1229 with a tweak: the OpenID Connect provider now only resolves the ID and role name from the claims. The roles themselves are defined in the configuration and include both the permissions and possible limitations for the CAs access is allowed to. This means you can’t include the allowed CAs in the OpenID Connect claims any more but hopefully this is fine.

Still missing for this PR to leave draft state are documentation adjustments, both internally and in the manual.

[partim]

Both implementation and documentation are done now. This now needs some testing, in particular the OpenID Connect parts, but it is ready for review now.

[partim]

Alright, I‘m calling this done. Now have at it ;)