Introduce Permitlets that allow to provide config fragments programatically

[ghenzler]

There are some cases where a declarative approach just has limitations (even though we support FOR and IF constructs). For those cases special permssions have to be set programatically at the moment. Doing works fine (in combination with the feature #212 or separate groups that then have to be created manually), however it can be complicated to manage such a setup:

• Content backups might not have been created with permissions in mind (if the flag is not set in the content package they are missing)
• If the software changes the behaviour how permissions are derived or if there was a bug in that part of the code there is content with invalid permissions. This either complicates the custom software (as it then has to cater for "repairing permissions", not only creating them) or groovy scripts have to be written to explicitly fix certain invalid content.

Also compare https://github.com/Netcentric/accesscontroltool/issues/212#issuecomment-346390867

To fix all this the idea would be to introduce Permitlets to the API as a SPI interface. A project could then implement an OSGi service and naming it with an OSGi property (e.g. permitletName, similar on how predicates are registered in AEM). That name could then be used in the AC Tool configuration to reference the result. The signature could look as follows:

interface Permitlet {
     List<AceBean> createPermissionsFor(Node node) {
          ....
     }
}

The permitlet could be referenced in the ACTool config as follows:

- permitlets:

   - FOR path IN [ path1, path2, path3 ]:

        - path: ${path}
          permitletName: "MyNameAsDeclaredInOSGiService"        

The big advantage of this approach would be that

• it can be used to fix old content as well (and not only on event when permissions are created programatically)
• it is easier to use as the plain JCR API and consistent with the "static part of the setup"

[kwin]

Since right now it is not possible to enforce the deployment and activation of an OSGi bundle before the ACTool is being triggered I would recommend to only allow implementations of this proposed SPI in java classes, which are compiled on the AEM side (through the ACTool itself), leveraging the Sling Scripting Java compiler.