Instead of creating a void type reader for every single PacketHandler registered, this just directly uses the consumer-like PacketHandler.
The distinction between ValueCreator and the normal PacketHandler was unnecessary given you could also just read something in a ValueCreator instance, effectively just being a consumer of a PacketWrapper instance.
Not perfect, but better. This prevents the path checks from exponentially increasing (if it weren't for the maxProtocolPathSize fail safe).
By default, a path will never go to a protocol version that puts it farther from the desired server protocol version, even if a path existed.
Otherwise as well as previously, *all* possible paths will be checked until a fitting one is found.
Negative examples if the new boolean is set to true:
A possible path from 3 to 5 in order of 3->10->5 will be dismissed.
A possible path from 5 to 3 in order of 5->0->3 will be dismissed.
Negative examples if set to false:
While searching for a path from 3 to 5, 3->2->1 could be checked first before 3->4->5 is found.
While searching for a path from 5 to 3, 5->6->7 could be checked first before 5->4->3 is found.
Assuming custom platforms like Bedrock protocol use the normal registering methods, they will have to change the boolean to false to revert to previous behavior (tho still somewhat better optimized).
Defaulting to submitting to the netty event loop caused issues more often than not - this also removes the `currentThread` flag and instead provides new scheduleSend methods so it is always obvious whether the packet is sent immediately.
The base plugin is usually applied by the java plugin, but since that has been moved into the platforms, cleaning was no longer applied to the root dir (created and filled by the universal submodule).
The Discontinued entry was a special edge case that could lead to a Metadata type returning null. Instead, just directly use null in the 1.8->1.9 code where it is checked against. Also renamed the Meta1_17Types entries to be in uppercase and properly represent their value type.
Lazily create the event if needed and share it with other filters when handling a metadata entry. Lastly, only add the additionally created meta once after the filter list, not once per filter.
This could mean life and death, see
`new Metadata(17, MetaType1_14.Float, event.meta()).value()`
vs.
`new Metadata(17, MetaType1_14.Float, event.meta().value())`
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
