When joining a server with connection latency > 1tick, repeated relative teleports (~ or ^) will desync the client and server; the server side will not move the player

What I expected to happen was...:
The player on server and client should behave in the same way

What actually happened was...:
On the server, player stops accepting movement updates and, in the case of /tp @s ~ ~ ~ ~ ~, is stuck in place. On the client, the player can still move, albeit a bit jittery.

Steps to Reproduce:
1. boot up a server and client
2. use high latency connection or control latency with an external program (i use clumsy)
3. make sure rtt is > 50*teleportFrequency ms
4. join server and have /execute as @a at @s run tp @s ~ ~ ~ run constantly (repeating command block, ticking function, or any other clock running the command)
5. run /particle flash ~ ~ ~ to observe your server side location

Root Cause:
Looking at provided decompiled code, if teleportPos is set in PlayerConnection, movement updates will be skipped. If a new teleport is issued before a PacketPlayInTeleportAccept is received from the client, teleportPos will remain set, blocking movement updates indefinitely until new teleports are no longer issued.

Suggested fix:
1. If the movement's final location is in a decent range of the teleported to location, make the client's position the actual position.
2. If it is outside of said range, update the client to the server's position.
This should eliminate the desyncs and allow client movement, while still keeping a validation for the movement packet (if the teleport was rather far away, it'll then always update the client to that location).