closes#5641
This has been mostly tested on Windows so far, where it offers substantial performance gains for compression.
On *nix, the performance advantage is smaller, since there's less overhead to creating new AsyncTask instances; however, the performance benefit is still clearly visible.
There are still some wrinkles to iron out, such as the dumb algorithm used for cycling through threads which wastes memory on small servers, but this change is mainly aimed at large servers, where the benefit will be clearly apparent.
In practice, this should reduce main thread CPU load by 10-20% on some of the largest servers, offering a large amount of headroom for increased player counts.
due to the extremely large performance cost of instantiating AsyncTasks, it's usually not worth bothering with async compression except for very large packets.
While this large overhead can be significantly reduced by using specialized threads, it's early days in the testing stages for such improvements, and for now, we still have this to deal with.
Since async compression is always used prior to player spawn, this change may slightly improve the performance of the pre-join stage of the game.
WARNING: This WILL have a performance impact on larger servers, but that's the price to pay for having crops actually grow.
The old overengineered method for doing this was causing glacially slow crop growth, vanilla parity issues and really just didn't make much sense. This method is probably incorrect too, but it will at least produce visible results.
this allows plugins to add their own mappings (though they should really be using StringToItemParser) without needing any legacy numeric ID bullshit in the mix.
all remaining submodules are now non-essential to running a server.
They are also versioned and updates can be done automatically using 'composer update'.
Finally, we can also put an end to the issue of translations being rendered incorrectly or being missing due to outdated submodules.
preset is now supported as its own key, and it's less confusing to present it separately, since that's how it's displayed in the server.properties also.
