This fixes issues with Servux and probably a crap ton of other bad mods. Purity on this front serves no real purpose than to say we're pedantic.
A future commit may remove all tracking of registered channels altogether. There's strong evidence (back to Minecraft 1.8, at least) that we don't have to track this data and only need to send channels for plugin message channels registered by Velocity itself. This will likely involve more testing to see if this uncovers client bugs with older versions of the game.
This commit backports the event manager from Velocity Polymer, with some changes for Velocity 1.1.x API compatibility:
- All event handlers run asynchronously. (While EventTask.async() exists, it is not useful in 3.0.0, but is provided as a migration aid for Polymer.)
- Event ordering is currently limited to the 5 levels available in Velocity 1.x.x.
This is about as optimized as it can get. Thanks to @Leymooo for the idea, I simply expanded on it. We optimize for the common 1-3 byte cases, and punt more "complicated" cases to the original VarInt writing function we had before.
Inspired by the approach described at the bottom of https://richardstartin.github.io/posts/dont-use-protobuf-for-telemetry
Given that we do a lot of varint writing as well, this should provide a small performance boost for larger/complex packets whilst not regressing hard on smaller packets.
This includes a test to ensure that the behavior is as expected and fixes the initialization loop so that the correct results will be given. Much thanks to @octylFractal for acting as my duck while trying to figure this out.
Inspired by the approach described at the bottom of https://richardstartin.github.io/posts/dont-use-protobuf-for-telemetry
Given that we do a lot of varint writing as well, this should provide a small performance boost for larger/complex packets whilst not regressing hard on smaller packets.
