fix(velocity): cancel modified packets

[Kowagirl]

The velocity PacketListener was not cancelling packets that were being modified by BTLP, leading to what I assume are a number of issues, but most notably players being invisible when they move into render distance.

I took a look at the Bungeecord equivalent for this class, and saw some logic absent from the velocity implementation on if the the packet should be cancelled, modified, or passed. In my testing, adding this into the velocity listener fixes the issue (though this was limited to my use case, ordered dynamic tab list, backend server handling scoreboard teams). I would be interested in if @proferabg had a reason for removing it in #766, or if this was just missed in the port.

I also took the chance to clean up this code a bit, as result should be reliable for determining if a modified packet should be sent, cancelled, or passed.

Also updating minecraft-data-api to include CodeCrafter47/minecraft-data-api#10, let me know if you want this is a separate PR.

[proferabg]

Yes this was missed by me. There was an issue of it sending duplicate packets and the tab list being malformed and I forgot to come back and fix this. Have you tested the tab list on all versions to confirm it works?

[Kowagirl]

Yes this was missed by me. There was an issue of it sending duplicate packets and the tab list being malformed and I forgot to come back and fix this. Have you tested the tab list on all versions to confirm it works?

Only tested against Velocity 3.4.0 with Paper 1.21.1. Where your general testing procedure to ensure functionally?

[Tig3r98]

Can confirm this is working with Paper 1.21.4 and Velocity 482, no more invisible players it seems.

[Tig3r98]

Looks like Paper 1.16.5-794 on Velocity 482 might be broken, but I didn't have time to test the same setup on older BTLP. I get added to the tablist as a raw player too, then after some time the raw version of me disappears. Needs more testing.