closes#5645
the code for this is borrowed from ItemEntity. I didn't feel like a base class was appropriate, and we can't (yet) declare constants in traits.
This change significantly reduces the amount of work done by event handlers. Instead of traversing all of the priorities and event parent chain multiple times, we reduce event handlers down to a simple list, which doesn't require any logic to iterate over.
Previously, calling an event with lots of parents costed more than an event which directly descended from Event.
In addition, we had to do a lot of usually useless work to check all priorities, when in practice, only NORMAL will be used in almost all cases.
This change makes it more cost effective to implement the feature suggested by #5678; however, it will still require additional changes.
closes#5670
I'm not super happy with this fix, since it can still be broken if StandardPacketBroadcaster is replaced by something else. However, fixing that problem is probably going to require internal BC breaks, which are not suitable for a patch release.
Split timings into tree reports
this will allow the timings site to display timings as a tree, instead of as a list as is done now, which will enable more precise identification of performance issues.
An example of this can be seen here: https://timings.pmmp.io/?id=302629
The format changes are fully backwards compatible, as the timings site
aggregates timings from timers with the same names, and doesn't limit
how much extra data can appear at the end of a line.
this gives a somewhat better overview of events, particularly if many plugins are subscribed to the same costly event (e.g. PlayerMoveEvent).
In addition, it allows us to see the frequency that events are occurring.
due to implementation quirks + some unforeseen ways these actions can behave, there can be as many as 53 actions in a single crafting request. This is an edge case, but it has to be catered for.
for some reason book edits generate a transaction in addition to BookEditPacket. PM has never used the transaction, and it doesn't pass anyway because CreateItemAction can't be used in survival mode.
However, since the strict validation introduced since ItemStackRequest, this dud transaction now causes the player to get kicked without these changes.
