Group members stored in a rep:members tree

storing group members in a dedicated rep:members tree is currently not
yet implemented.

• jr 2.x node type definition allows SNS which are not supported in oak
• jr 2.x node type definition stores members in residual properties, which
  up to now doesn't allow to use a specific property index.
• the jr 2.x implementation is rather cumbersome as it doesn't allow
  to change the configuration later on such that existing groups can
  benefit from the config change.
• the node names in the tree structure would rely on userId being equal
  to the principal name, which is not mandated.

for a new implementation in oak i see the following variants to provide this
feature:

variant 1:

• drop SNS
• change member-property to a multivalue rep:members property in the
  node hierarchy -> same index as for non-tree implementation
• config change will result in the member-tree to be created also for
  existing groups.
• even if member-tree option is enabled the members are stored in the
  default mv property and just have a tree structured added if required
  based on the config option.
• adjust xml import of user content accordingly

pros:

• dedicated property index for rep:members property defined by rep:Members
  works out of the box -> performance of membership lookup.
• fixing SNS definition
• fixing confusion of uid with principalname

cons:

• not backwards compatible out of the box
• updating membership might not be efficient
• we need to add backwards compatible behavior when reading and querying
  existing membership information or provide an upgrade path that converts
  'old' structure to the new one upon repo upgrade

variant 2:

• rebuild use same logic as in JR2.x to build tree structure but include
  fixing the principalName/uid issue.

pros:

• backwards compatible (no upgrade path required)
• most probably changing membership of a group was more efficient

cons:

• efficient lookup of membership doesn't work (AFAIK the property index is limited
  to named properties). thus we probably need to adjust the query/index logic such that
  a property index can be created for residual properties defined by the rep:Members node type
• SNS problem not addressed -> might cause failure upon upgrade