Bring back binary cache for CraftingDataPacket and other expensive join sequence packets

[dktapps]

Problem description

In PM3, we used to cache a compressed CraftingDataPacket to avoid the performance hit on join of re-encoding the packet every time.

We stopped caching a compressed buffer (c4d35d5) because it's better for compression efficiency to let the network system compress all the pre-spawn data into one giant batch rather than caching several smaller ones. In addition, caching this way prevented plugins from seeing the packet via DataPacketSendEvent.

However, since this changed to caching a plain unencoded CraftingDataPacket object, this meant that we went back to paying a significant performance penalty for encoding it every time a player joined.

(We used to have buffer caches inside DataPacket in PM3, but those were removed due to technical unsoundness - we couldn't invalidate them on modifications. Removing these buffer caches caused other performance hits in PM4 that were fixed in 4.18.0 with the introduction of EntityEventBroadcaster - essentially just a hack to allow encoding a packet once and sending it many times, like we did in the PM3 days.)

In addition, because CraftingDataPacket and friends have many thousands of child objects, they cause a big drag whenever they land in the GC root buffer and the GC wastes CPU time trying to get rid of them.

Bringing buffer caches back is tricky now because of the aforementioned DataPacketSendEvent. We can't fit buffer caches into the existing model of DataPacketSendEvent. This means that if we were to start caching a raw buffer, plugins couldn't use DataPacketSendEvent to modify cached packets anymore. We'd need a new mechanism to enable this.

Proposed solution

Cache pre-encoded (non-compressed) buffers of:

• CreativeContentPacket
• CraftingDataPacket
• BiomeDefinitionListPacket
• AvailableActorIdentifiersPacket

This will enable these packets to be sent during the join sequence with minimal overhead.

For the event problem, perhaps introduce DataPacketRawSendEvent?
I don't like it, but then I never liked any of these packet events anyway since they're awful for performance.

Alternative solutions that don't require API changes