Allow incremental update

[ghenzler]

For large instances, applying the AC Tool configuration can take three hours and longer (scales with the amount of content or no of paths) due to the fact that all ACEs are deleted and reapplied to the content paths.

It would be good to compare for each path the configuration with the actual ACL. The work from #127 has made this easier (now only ACEs for authorizables in config outside of "configuration path space" are deleted up front, changes to the ACL of a certain path are made as a conceptional unit).

The biggest challgenge is the use of the AEM CqActions class that operates via an algorithm onto the ACL, hence it is not just comparing the privileges list from config with the privileges on the actual path.

[ghenzler]

There are two options to achieve incremental update of the ACL of one path (simple compare of configured ACL with existing ACL does not work due to CqActions):

Option 1:

While installing the ACLs to the paths, have a second "test session" running a long that the ACL is applied to before saving it to the actual session. The "test session" would never be saved and refresh(false) (reverting the session) would be called after testing each path (to not grow a large change set). After applying the ACL for a path to the "test session", the resulting privileges could be compared to what the actual session has, if it is not the same the ACL is applied to the actual session and saved, otherwise the path can be skipped for the actual session. (NOTE: hasPendingChanges() can not be used because the current algorithm removes and adds the entries, this will be recorded as pending changes even if the ACEs are the same).

CON: Parallel sessions might not be considered good practice (see #146 that came indirectly from Adobe), however for this use case (and using the refresh() after every path is should be fine)
CON: No improvement to #48
PRO: Fairly simple to implement, no change of behaviour.

Option 2:

For every path and each AuthorizableConfigBean, use a fake authorizable to see what CqActions would create (use a fake authorizable to ensure no automatic merging by CqActions is done). This creates a mapping between an actions set to the resulting privileges at the very path (resulting privileges are dependent on the path and particularly if there is a jcr:content sub node). Remove the fake authorizable from the ACL after the mapping is produced.

After having a mapping from actions to privileges, the existing ACL can be easily be compared to the configured permissions.

Pro: This would solve #48 (as the automated merging in CqActions is cricumvented)
Con: Potentially the resulting ACL becomes longer if using actions (however tuning is always possible when using privileges directly).
Con: Maybe we are not 100% backwards compatible (although in theory the resulting behaviour should be exactly the same, also delivering this with 2.0.0 should make it clear that behaviour can slightly change)

[ghenzler]

Introduced a global_config flag that allows to switch between incremental and "classic" installation (default is incremental):

- global_config:
    installAclsIncrementally: true

By running the classic way first and then the incremental way on top it is really easy to test if the new incremental approach does not introduce any changes: "No changes were made to ACLs (session has no pending changes)" is printed in the result then.

[ghenzler]

Implemented Option 2 from #155 (comment)

[chetanyajain]

Can we update documentation section to add the global_config for installAclsIncrementally?

[ghenzler]

installAclsIncrementally is undocumented because it was only used for testing the 2.0.0 release (for quickly switching between the 1.x and 2.x way). Today it is still in but the plan is to remove it soon completely.

@chetanyajain Do you have a reason to not install ACLs incrementally? (incremental install is the default for 2.x)

[kwin]

Documented now with 5654dd4 as useful for external sync sometimes.