Not sent small player position changes makes validation hard on servers

The bug

The client does have a too large threshold for not sending position changes to the server.

What this small inaccuracy in player position causes, is:

• Pressing forward while looking mostly against a wall causes the player to not move smoothly, but just one every second (due to forced position send every 20 ticks)
• In edge cases: Clipping through block edges from server's view
• Third-party extensions to server software which try to detect cheating have huge problems to validate movement in water with the client's movement algorithm, because multiple of such small movements following each other, trying all combinations of multiple small movements has expotential complexity.
• During a jump with just slight horizontal motion, the horizontal motion at the peak of a jump is not sent to the server.
  * Jump once and building a block below you while inair, then stop moving - For the server, you will not be marked onGround on the server and float slightly above the block you just build (until the forced position send every 20 ticks).

Not as important reasons to change this:

• Various command block possibilities and testfor might want to check various things exactly but they can't
• inability of always correctly checking whether a player collided with a wall: if the move the player did was just very near a wall, the next move might be less than the minimum movement change to send a position update so he did not collide server-side only
• whether a player moved onto a pressure plate or stopped just before can't be really decided
• whether the player is moving slightly while collided with a wall, some puzzle adventures maybe want to check whether the player is moving at all or not

Suggested fix:

Affected method: net.minecraft.client.player.LocalPlayer.sendPosition()
Code snippet (this one from 21w39a):

        if (this.isControlledCamera()) {
            double $$4 = this.getX() - this.xLast;
            double $$5 = this.getY() - this.yLast1;
            double $$6 = this.getZ() - this.zLast;
            double $$7 = (double)(this.getYRot() - this.yRotLast);
            double $$8 = (double)(this.getXRot() - this.xRotLast);
            ++this.positionReminder;
            boolean $$9 = $$4 * $$4 + $$5 * $$5 + $$6 * $$6 > 9.0E-4D || this.positionReminder >= 20;
            boolean $$10 = $$7 != 0.0D || $$8 != 0.0D;
            if (this.isPassenger()) {

Suggested change:
- boolean $$9 = $$4 * $$4 + $$5 * $$5 + $$6 * $$6 > 9.0E-4D || this.positionReminder >= 20;
+ boolean $$9 = $$4 * $$4 + $$5 * $$5 + $$6 * $$6 > 4.0E-8D || this.positionReminder >= 20;

Because of the squared distance context:
9.0E-4D refers to the distance 0.03
4.0E-8D refers to the distance 0.0002

This suggested new "small movement threshold" is still far below any double-precision floating point inaccuracy.

Other technical reason to implement this change

The code review from @Pokechu22 (first comment) does show that the constant 9.0E-4 is outdated.
Minecraft 1.9 increased the "relative movement" server->client packets from 1/32 = 0.03125 to 1/128. 0.03125 which is very similar to the the 0.03 distance.
It can be expected that the constant 9.0E-4 aka 0.03 was chosen in relation to te accuracy of the "relative movement" packet. So as you increased its accuracy, it is more than neccessary to follow up on this change with the suggested fix in this issue.

Downsides of the fix

None. There is no performance impact of this code change. The network usage at most increases to that of a player sprinting, which already happens often during the game.