Autoexport override exporting of security configuration .meta:category system properties for better developer experience

In the new v14 security model, the (product provided) security configuration (will) all use .meta:category: system for the following properties:

• hipposys:userrole
• hipposys:userroles (and with .meta:add-new-system-values: true)
• hipposys:users (and with .meta:add-new-system-values: true)
• hipposys:groups  (and with .meta:add-new-system-values: true)

for the product or project provided configuration nodes (the built in bootstrapped users like admin or groups like admin, author, etc) with .meta:category: config:

• users (node type hipposys:user or hipposys:externaluser)
• groups (node type hipposys:group or hipposys:externalgroup)
• domains authroles (node type hippo:authrole)

to prevent being destructive on runtime production changes of these property values.

Important note: everything else of the domain security configuration (including hipposys:authrole property hipposys:role) remains category config if it was bootstrapped as category config!

This means that other runtime production changes to .meta:category: config nodes (including new domain authroles) must be merged back into a project its bootstrap (yaml) configuration to ensure those runtime production changes are not (possibly) destroyed on a subsequent deployment!
This is not new behavior but the case since the introduction of the new configuration management in v12.

However, marking the above 4 properties as .meta:category: system has a downside effect for the developer experience because autoexport now no longer will export local development changes either.
This is cumbersome (and a likely unexpected behavior change) because a developer then must manually edit and add such changes directly through the yaml files.

To prevent this undesirable side-effect, the autoexport service will use overriding behavior for specifically and only these 4 properties of these 5 node types (hipposys:user, hipposys:externaluser, hipposys:group, hipposys:externalgroup, hippo:authrole), by still exporting them, including the intended .meta:category: system, and for the multi value properties also .meta:add-new-system-values: true.

For groups (/hippo:configuration/hippo:groups), roles (/hippo:configuration/hippo:roles) and the new userroles (/hippo:configuration/hippo:userroles) .meta:residual-child-node-category: system is used, and to support adding new groups, roles and userroles during development the default provided autoexport configuration is extended though its autoexport:overrideresidualchildnodecategory property with the following values, marking these paths as category config for local development only:

autoexport:overrideresidualchildnodecategory: ["/hippo:configuration/hippo:groups: config",
                                               "/hippo:configuration/hippo:roles: config",
                                               "/hippo:configuration/hippo:userroles: config"]

Runtime (only) added groups, roles and userroles therefore are protected from accidental removal after a new deployment.   

The merging back of runtime production changes as mentioned above, a developer/admin can/should make use of the Configuration Verifier.
Easier to use tooling for more directly merging back runtime configuration changes into a development setup is intended to  be added in a (minor) next release soon.