1. User::addGroup has to be allowed to update the old group
2. Replace use of string constants to identify cache class,
that's prone to typos and errors. Instead, use private constants
3. Update cached user group memberships in place upon modification.
Before UserGroupManager, we've used to do that - this saves some
DB queries, and is better for correctness - for example UserrightsPage
is adding new memberships and then immediately reads from replica,
expecting it's changes to be there already.
We do not know however how many other cases there are which rely
on this pattern, so implement in-place cache update.
Bug: T255330
Change-Id: Ia5ae0e22d4156fd5e4b9aa7eeb801902e79803d1
Additionally, User::checkAndSetTouched was made public and
marked as @internal. Eventually, as User class refactoring
continues, I would expect this to be replaced by some service.
Bug: T252621
Change-Id: I53533f494950d08ee5ed1ec54d24958c21e7b3aa
Introduce a UserGroupManagerFactory and UserGroupManager.
The factory utilizes the same pattern as RevisionStore
for access to user groups of a foreign wiki.
Some user group related methods were ported from User
and UserGroupMembership and deprecated, more methods to
be moved over in future patches, not to make this one to large.
Eventually as all the group-related methods are moved and their
usages are replaced, the need for the UserRightsProxy will disappear,
thus it also will be deprecated and removed. Currently for backwards
compatibility, I've had to create artificial UserIdentityValue
objects in some of the deprecated methods to avoid making transitional
temporary methods in the UserGroupManager that would take user ID
instead of the UserIdentity. All of this will go away once migration
to UserGroupManager is completed.
Bug: T234921
Change-Id: If29c6a03dfdbb80b2e846243f7e384b334da9f07
