Implement Admin APIs for Roles <-> Permissions relationships

[mikelax]

Feature Overview

Is your feature request related to a problem? Please describe.
As an admin usher user, I would like to have APIs available to manage Permissions for a given Role. I would be able to list, create, & remove permissions for a Role.

API Design

Status	URL	Auth	Params	Notes
✅	PUT /roles/:role_key/permissions	bearerAdminAuth	required Array of Permission keys: body	Add a Permission to Role
✅	GET /roles/:role_key/permissions	bearerAdminAuth	role_key: path, required	List Permissions within a Role
TODO	DELETE /roles/:role_key/permissions/:permission_key	bearerAdminAuth	persona key: path, required	Remove a Permission from a Role

Implementation Notes

• The source files should be placed in the src/api_endpoints/roles folder

Questions

1. Should the POST take a single permission key or should we enhance to accept either a single key or an array of keys? Yes, and also change to PUT
2. What happens if the PUT is partially successful? ie. PUT sends 4 permission keys and 3 are valid and one is invalid? Are the three added with 200 success, three added with 400 error response, or none added with 400 error response?

[k1ch]

@mikelax Regarding POST /roles/:role_key/permissions, I recommend we use PUT method which accepts an array of permission keys similar to PUT /personas/{key}/permission

[k1ch]

@mikelax Regarding the second question, I prefer returning a 400 error response with no permissions added, as it simplifies the API behavior and aligns with the logic we implemented for PUT /persona/{key}/permissions, where we validate all permissions before assigning them to the persona.

[mikelax]

@mikelax Regarding the second question, I prefer returning a 400 error response with no permissions added, as it simplifies the API behavior and aligns with the logic we implemented for PUT /persona/{key}/permissions, where we validate all permissions before assigning them to the persona.

@k1ch I am ok with this as I agree it is simple to understand and I like consistency if we have already started with this implementation elsewhere.