Enhanced membership management and proxy support

[wadahiro]

Summary

• Enhanced group and project membership management
• Added HTTP proxy and timeout configuration support
• Improved error handling and code structure
• Updated GitLab access levels to align with current API

Changes

Features

• Group/Project Membership Management: Performance-optimized reimplementation of user membership management for GitLab groups and projects
• HTTP Proxy Support: Added configuration options for HTTP proxy and connection timeouts
• Groups/Projects Attributes: Added consolidated group/project attributes with configurable default access levels and support for id#accessLevel format to specify custom access levels
• Regex Support: Added new configuration attributes for regex pattern matching alongside existing groupsToManage configuration

Improvements

• Error Handling: Improved error handling for membership operations with better logging and recovery
• Code Refactoring: Major refactoring of processing classes to reduce code duplication and improve maintainability
• Access Levels: Updated to use current GitLab access levels (removed deprecated master role, now using maintainer, added planner role)

Bug Fixes

• Removed inappropriate StringEscapeUtils.unescapeXml usage that was causing issues with special characters

Breaking Changes

• The master access level has been replaced with maintainer to align with current GitLab terminology
• Changed groupsToManage configuration from comma-separated string to String[] array type
• Group/project membership associations in midPoint require different configuration - see sample configurations below for details

Sample MidPoint Configuration

Important: Unlike previous versions, we must now use subjectToObject direction for associations.

Group/Project Membership Association Example

<attribute>
    <c:ref>ri:groups_as_developer</c:ref>
    <fetchStrategy>explicit</fetchStrategy>
</attribute>
            
<association>
    <c:ref>ri:group-developer</c:ref>
    <displayName>Developer membership for group</displayName>
    <tolerant>false</tolerant>
    <kind>entitlement</kind>
    <intent>group</intent>
    <direction>subjectToObject</direction>
    <associationAttribute>ri:groups_as_developer</associationAttribute>
    <valueAttribute>icfs:uid</valueAttribute>
</association>

Note: We need to add <fetchStrategy>explicit</fetchStrategy> to the attribute configuration for proper operation. By default, membership data is not fetched for performance reasons, so explicit fetching is required to retrieve membership information.

The following attributes are available for different access levels:

For Groups:

• ri:groups_as_guest - Guest access (10)
• ri:groups_as_planner - Planner access (15)
• ri:groups_as_reporter - Reporter access (20)
• ri:groups_as_developer - Developer access (30)
• ri:groups_as_maintainer - Maintainer access (40)
• ri:groups_as_owner - Owner access (50)

For Projects:

• ri:projects_as_guest - Guest access (10)
• ri:projects_as_planner - Planner access (15)
• ri:projects_as_reporter - Reporter access (20)
• ri:projects_as_developer - Developer access (30)
• ri:projects_as_maintainer - Maintainer access (40)
• ri:projects_as_owner - Owner access (50)

Consolidated Groups/Projects Membership Association Example

For simpler use cases, we can use consolidated attributes where the access level is determined by the defaultAccessLevel configuration.
This is ideal when we want midPoint to control membership (add/remove users) while allowing GitLab administrators to manage access levels directly in GitLab:

<attribute>
    <c:ref>ri:groups</c:ref>
    <fetchStrategy>explicit</fetchStrategy>
</attribute>

<association>
    <c:ref>ri:group</c:ref>
    <displayName>Group membership (default access level)</displayName>
    <tolerant>false</tolerant>
    <kind>entitlement</kind>
    <intent>group</intent>
    <direction>subjectToObject</direction>
    <associationAttribute>ri:groups</associationAttribute>
    <valueAttribute>icfs:uid</valueAttribute>
</association>


<attribute>
    <c:ref>ri:projects</c:ref>
    <fetchStrategy>explicit</fetchStrategy>
</attribute>

<association>
    <c:ref>ri:project</c:ref>
    <displayName>Project membership (default access level)</displayName>
    <tolerant>false</tolerant>
    <kind>entitlement</kind>
    <intent>project</intent>
    <direction>subjectToObject</direction>
    <associationAttribute>ri:projects</associationAttribute>
    <valueAttribute>icfs:uid</valueAttribute>
</association>

Note: When using ri:groups or ri:projects, members are added with the access level specified in the connector's defaultAccessLevel configuration.
After initial provisioning, access levels can be managed directly in GitLab while midPoint continues to control membership.