This PR serves as a necessary prelude for Core/Movement: Improve player movement .

Core/Movement: Improve player movement needed proper client transfer control. Up until now, two fields served that purpose: Unit::m_playerMovingMe and Player::m_unitMovedByMe. There are 2 issues with them:

• They are difficult to understand and reason with (just look at the current implementation of Player::SetMovedUnit() if you don't believe me).
• They are not updated when client A looses control over Player B because Player B is under the effect of a CC such as Sheep or Fear. player_B->m_unitMovedByMe will still points toward player_B. What is missing here is what I call an API that gives the "real-time client control status" of player_B.

In order to fix these problems, this PR introduces 3 notions:

1. Base client control: assuming I'm correct (please correct me if I'm wrong here), there are only 2 ways a client can have 'client control' over a unit in the game: a) the unit is a player and the client logs into the world with that player (I call this Player unit, the "base player" of that client). b) a (base) player charms another player or unit (this includes a Priest MCing another unit or a Player mounting a vehicle). Therefore, by looking at a unit's UNIT_FIELD_CHARM and UNIT_FIELD_CHARMEDBY values, we can tell who/what is really moving that unit. [1]

2. Real-time client control: On top of the base client control, the server will send to the client SMSG_CONTROL_UPDATE messages when the client should loose/regain control over a unit because a CC is applied/removed from that unit. A client could therefore have base client control but temporarily loose actual control while the CC is active. I call this real-time client control. Knowing the "real-time client control status" of a unit is needed when we need to change the speed of a unit for example: if the server controls the unit, we need to send a SMSG_MOVE_SPLINE_SET_RUN_SPEED message to the client to inform of the speed of change. if the client has real-time client control, the server needs to send a SMSG_FORCE_RUN_SPEED_CHANGE message (and expect an ACK response).

3. A GameClient entity. Instead of player_B->m_playerMovingMe pointing to player_B, we now have gameClient_A->_activeMover pointing to player_B. And if control is lost, gameClient_A->_activeMover is NULL. Same for player_B->m_unitMovedByMe which also points to player_B. Instead, we have player_B->_gameClientMovingMe which points to gameClient_A. This is much more understandable than the cyclic references m_playerMovingMe and m_unitMovedByMe.

Base client control API:

• Unit::isCharmerOrSelfPlayer
• Unit::GetCharmerOrSelf()
• Unit::GetCharmerOrSelfPlayer
• Unit::GetCharmedOrSelf()

Real time client control API:

• Unit::IsMovedByClient()
• Unit::IsMovedByServer()
• Unit::GetGameClientMovingMe()
• GameClient::GetActiveMover()
• GameClient::IsAllowedToMove(Unit* unit)

Real time client control is implemented using the exchange of the following packets:

1. S->C SMSG_CONTROL_UPDATE
2. C-> CMSG_SET_ACTIVE_MOVER and/or CMSG_MOVE_NOT_ACTIVE_MOVER

[1] If the unit is a creature

• and if UNIT_FIELD_CHARMEDBY == 0, then nobody has "client control" over that unit (in other words, the server has control over that unit).
• if UNIT_FIELD_CHARMEDBY is set, then that player has "client control" over that unit (vehicle or mind control).

If the unit is a player

• and if UNIT_FIELD_CHARMEDBY == 0, then we are in a "base player" situation.
• if UNIT_FIELD_CHARMEDBY is set, then that player has "client control" over that unit (e.g. mind control).

Target branch(es): 3.3.5/master

• 3.3.5
• master

Tests performed:

Tested in game. Vehicles work. Weird scenarios like player_A (a priest) MCs player_B and then player_C fears player_B also work.