fix(UserUpdateAction): rely on client.user when ids match

[kevinbioj]

Please describe the changes this PR makes and why it should be merged:

When the UserManager cache is disabled, updating the client user will result in a crash. The user update action gets the old state of the user via the UserManager cache, even if it's the client user. However, when it's disabled, nothing is being returned and so newUser._update throws a type error.

This fix makes the code get client.user if client.user.id and data.id are equal.

Status and versioning classification:

• Code changes have been tested against the Discord API, or there are no code changes
• I know how to update typings and have done so, or typings don't need updating

[iShibi]

What if the UserUpdate gets triggered by a non-client user who isn't cached? The newUser will be undefined in that case too and the same error will occur. I think you should use the getUser method here.

[iShibi]

There is a chance that getUser will too return undefined if the client didn't opt for USER partial. The GuildMemberUpdate action handler does it the right way.

[kevinbioj]

There is a chance that getUser will too return undefined if the client didn't opt for USER partial. The GuildMemberUpdate action handler does it the right way.

Discord's USER_UPDATE is only emitted for client user's changes. Changes for other users have to go through the GUILD_MEMBER_UPDATE event, where the UserUpdate action is not being called if the user wasn't in cache already.

That means if this action is being called by anything else than the actual USER_UPDATE event, the user is in the cache (logic in GuildMemberUpdate action, and the PresenceUpdate action performs a User#equals using the same data, meaning the action is never being called). Which also means the only user that may not be at this point, is the client user.

Now, if people have been messing enough with the caches, the library shouldn't be handling that for them. Enabling the GUILD_MEMBERS intent and disabling the GuildManager or the UserManager cache(s) is definitely going to lead to undefined behaviors but would be up to the end user responsibility imo.

The client user would be the only exception to that rule as the action is being called no matter what intents are being enabled. Which would mean the crash would occur as soon as the UserManager is disabled (#6510).

That's mainly why I haven't gotten further in the patch, thought that wouldn't be "that useful". That's also why I'd like to hear some maintainers point-of-views because I must admit I'm not very confident on that particular point.