[Feature] Effective permission API responses

[fmigneault]

Context

Effective permissions on a resource for users was introduced in #135.
Using the query parameter in /users/{usr}/resources/{id}/permissions?effective=true (*) allows to obtain the effective permission of that specific user/resource combination including permissions of group the user is member of.

Although both inherit and effective flag consider the permissions of groups the user is part of, the effective flag goes an extra step to rewind up to the service any permissions that apply to children resources, while inherit will only resolve the user & group permissions of the specific resource. This means that a recursive-permission placed on a parent resource at higher level than the current resource will be shown by effective but not by inherit as the permission is not set directly on that resource.

Feature

We could extend the effective feature for routes:

• /users/{usr}/resources (1)
• /users/{usr}/resources/{id} (2)
• /users/{grp}/services (1)
• /users/{grp}/services/{name} (2)

Instead of reporting the effective permissions only for a specific resource (eg: (*) route), these new routes would obtain the scoped resource/permission tree for the given user/group.
The service routes would simply extract the resource-id corresponding to it, and then proceed normally as for the resource routes.
(note: user's effective permission would be equal to effective direct permissions + all of his groups effective permissions).

(1)
In the case of no resource-id/service-name provided, the operation is executed recursively for all resources.
side note:
To avoid costly double "recursive" operations (one going down looping children resources, and the other going up to the service to apply effective permissions), we should only process going upward (from leaves to service) and apply permissions on top of one-another (with sets or similar).

(2)
In the case of resource-id/service-name provided, we directly rewind the resource tree to the top service and add effective permissions along the way with every new parent resource explored.

In both case, we need to consider the permission resolution scheme (#342).