Problem: We sometimes use UserTo allow service objects to represent users on a for safe cross-wiki database other than the local one. This has always been ickyoperations, but is becoming more problematic with the introduction of actor IDs,we need t make all entity objects aware of which wiki they belong to. since the same anonymous user (IP or "Foo>Bar" style cross-wiki user name) will have different actor IDs on different wiki databasesUserIdentity is so far lacking this information.
Solution: Allow User objects to know which database they belong to,Similar to what we do with PageIdentity (and soon with RevisionRecord), UserIdentity should get the following methods:
```lang=php
public function getWikiId: string|false;
public function assertWiki( string|false $wikiId );
```
And methods that return IDs that are bound to specific databases need to assert the wikiId:
```
public function getId( $wikiId = self::LOCAL ): int;
public function getActorId( $wikiId = self::LOCAL ): int;
```
For backwards compatibility, calls to getId() and getActorId() with no $wikiId provided should not yet fail if the user belongs to another wiki, but merely trigger a deprecation warning.
Steps
[] add wiki ID to UserIdentity
[] make getId() and getActorId() trigger a warning if $wikiId is LOCAL but the object belongs to another wiki. If $wikiId is provided but mismatches, throw.
[] after ensuring the above deprecations do not cause problems, make getId() and getActorId() always throw if $wikiId mismatches.
Side notes:
* getId() should at some point be renamed to getUserId() for clarity. If we do it now, getUserId() count immediately throw on mismatching $wikiId.
* It should not be possible for a UserIdentity to have a user ID but no actor ID. so they can lazy-load correctly.If a user ID is given, This should be reflected by a getWikiId() method in the UserIdentity interfacean actor ID MUST also be given. We are already doing a similar thThere may however be existing for similar reasons in RevisionRecord.tests that don't follow that rule.