Topic / k1ch / Introduce GET:/permissions and GET:/clients/{client_id}/permissions APIs

[k1ch]

Overview

• feat: topic/k1ch/introduce API - GET/permissions
• feat: topic/k1ch/ introduce API / GET/clients/{id}/permissions
• chore: db-admin-permissions / add tests for getPermissions
• chore: k1ch / introduce test for GET:/permissions
• chore: k1ch / add test for GET:/clients/{client_id}/permissions

Open API Spec updates

Your PR Checklist 🚨

❤️ Please review the guidelines for contributing to this repository. Our goal is to merge PRs fast 💨 .

• Check your code additions will fail neither code linting checks nor unit tests.
• Additional units tests have been added to prove code updates work and fixes are effective
• Additional documentation has been added (if appropriate)
• Update Assignee field to yourself

Issue Reference

Partially completes #110

Open Questions or Items to Callout

[k1ch]

@mikelax For roles, we have both GET:/roles and GET:/clients/{client_id}/roles. Should we introduce both APIs for permissions to stay consistent or Client Admin API is sufficient?
Introduced both GET:/permissions and GET:/clients/{client_id}/permissions

[mikelax]

@mikelax For roles, we have both GET:/roles and GET:/clients/{client_id}/roles. Should we introduce both APIs for permissions to stay consistent or Client Admin API is sufficient? Introduced both GET:/permissions and GET:/clients/{client_id}/permissions

Thanks @k1ch , I see you already implemented both URL paths, I think that makes sense to stay consistent. Hopefully its similar logic under the hood.