add coverage for removing all user settings on deletion + test coverage

[nathangavin]

Description

Please include a description of this change and which issue it fixes. If no issue exists yet please include context and what problem it solves.

fixes #23672

Checklist

• [✔] I have understood, reviewed, and tested all AI outputs before use
• [✔] All AI instructions respect security, IP, and privacy rules

Review

• Functional review done
• Potential edge cases thought about (behaviour of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• New documentation added or existing documentation updated

[chippison]

I've checked the code and done some functional tests, overall it everything works as intended. Deleting a user does remove the settings from the DB

There are a couple of edge case issues codex found though:

[P1] User deletion can leave legacy per-user data behind when one observer throws
Basically, if a plugin throws an exception when deleting a user, it could leave some data behind and not clean it up

• Was able to recreate this by creating a local plugin that throws exception on UserDelete
• Codex recommendations (you can just use this to get a starting point):
  1. Add direct legacy cleanup in deleteUserOptions() for MobileMessaging + ProfessionalServices keys (smallest blast radius).
  2. Keep event-based cleanup, but isolate observer failures per callback for this event path.

[P2] Migration strategy for ProfessionalServices scales poorly with user count

• wasn't really able to recreate this one, but seems like some DB query optimisation needed
• Codex recommendations: (you can just use this to get a starting point):
  1. Load ProfessionalServices.DismissedWidget.% once, group by login in PHP, then write/delete once.
  2. Keep logic but batch by login chunks with tighter SQL (still more churn than option 1).

[chippison]

I have checked the changes and it looks good from my end.
I also have done another round of testing and can confirm that:

• when a user is deleted, its legacy settings are also deleted.
• when a new user is created using the previous username, it does not follow/reuse the settings of the old user.

[sgiehl]

Didn't have time for any testing and only performed a rough code review

[sgiehl]

Tried doing a more detailed review now and left some further comments around possible improvements/fixes.

[sgiehl]

some last comments, afterwards that should be good to go.