MID-8802 Added displayName and preferredName to UserType

[kay1313]

Summary

This PR introduces UserType.displayName and preferredName, and updates selected presentation paths to use displayName instead of fullName.

The goal is to separate:

• fullName → legal/full name
• preferredName → user-preferred visible name
• displayName → computed, stored effective display name used in UI/notifications

---

Core behavior

displayName is now model-maintained:

displayName = preferredName (if non-empty)
           else fullName
           else null

• Implemented in projector (AssignmentHolderProcessor)
• Stored in repository and queryable
• Consumers can rely on getDisplayName() without fallback logic

---

Scope of changes

1. Schema & Repository

• Added preferredName and displayName to UserType
• Extended Sqale/native repo mappings and query support

2. Model

• Introduced projector logic to compute and persist displayName
• Generates secondary deltas when needed

3. Presentation (GUI)
Switched selected user-facing labels from fullName → displayName:

• user summary/header
• sidebar current user
• access request labels
• delegation UI
• certification / assignment UI
• merge details
• generic object labels (via utilities)

4. Search / Reporting
Added displayName to:

• searchable user fields
• default/available user list columns
• built-in user report export

5. Notifications

• Notification formatting now uses displayName for user labels
• Covers requestor/requestee and reference-based display helpers

---

What was intentionally NOT changed

• fullName semantics (remains legal/full name)
• identity-related logic (OID, name, DN/CN, matching)
• debug/repository DTOs (keep raw stored values)
• broad generic helpers with cross-cutting impact

This is a targeted presentation-layer shift, not a global rename.

---

Notes / impact

• Existing users need recompute to populate displayName
• Some tests were adjusted due to new computed/stored field behavior

Detailed Impact (by area)

Area	File(s)	Change	Why
GUI utilities	WebComponentUtil.java	Use displayName	Centralize user label semantics
Search	SearchBoxConfigurationBuilder.java, SearchableItemsDefinitions.java	Add displayName	Make new visible name searchable
Access UI	AccessRequestMixin.java	Use displayName	Show preferred name in requests
Delegation	DelegationEditorPanel.java	Use displayName	Align delegation labels with UI naming
User tables	ColumnUtils.java, DefaultColumnUtils.java	Add column	Expose displayName in lists
Sidebar	SideBarMenuPanel.java	Use displayName	Show correct current user label
Summary	UserSummaryPanel.java	Use displayName	Replace header label
Certification	CertCampaignDto.java, DirectAssignmentCertGuiHandler.java	Use displayName	Consistent user labeling
Merge UI	MergeObjectDetailsPanel.java	Use displayName	Show effective name
Selection UI	PageAttorneySelection.java	Add column	Show both names
Core util	ObjectTypeUtil.java	Update	Align helper behavior
Model	AssignmentHolderProcessor.java, Components.java	Compute displayName	Core logic
Visualization	Visualizer.java	Use displayName	UI consistency
Notifications	BaseEventImpl.java, ValueFormatter.java, etc.	Use displayName	Notification text
Repo	SqaleUtils.java, MUser.java, QUser.java, QUserMapping.java	Persist fields	Storage + query
Ninja	export classes	Adjust fields	Keep export consistent

---

Result

• displayName becomes the single source of truth for visible user name
• UI/notifications are aligned with user-preferred naming
• fallback logic is centralized in model instead of duplicated across code

[1azyman]

• Release notes need a bit better description, mainly in:
  ** Upgrade From MidPoint 4.9 (to be renamed to 4.10), removed content that's not relevant for upgrade 4.10->4.11.
  ** Changes In Initial Objects Since 4.10, again remove content that's not relevant
• Initial object template for person (380-something.xml) is missing display name mapping, which will take value from preferredName (if it has value) or from fullName.
• I see few replacements in GUI from fullName -> displayName.
  Customers will not have users with displayName populated right after upgrade, wouldn't it be better to use WebComponentUtil.getDisplayNameOrName() or something similar new that will return something more gracefully like displayName/fullName/name (in this order)?
  Or more probably in ObjectTypeUtil.getDisplayName(ObjectType) return displayName or fullName...
  I'm not sure, just to make it less painful for customers. I was looking at SidebarMenuItemPanel, UserSummaryPanel, AccessRequestMixin. Something that later can be "switched of" and to use only displayName in next versions.
  I think this graceful handling is not relevant for reports and backend code.
• More notes will be added as didn't have time to go through all the code yet.

[1azyman]

Please revert container ids changes and only create new id for new container (display name column). They don't have to be ordered. If we leave it shifted like this, diff during upgrade will display more "fake" changes since container with id=8 is now different then in previous version. If just displayName(id=12) is added, only that one will be picked up when object is used during diff operation. There's also "natural keys" for some containers defined, but it's not everywhere, so we want to stay on safe side.