Default to not creating snapshots in BlockState getters

[me4502]

Is your feature request related to a problem?

Around a decade ago the Bukkit API swapped to creating snapshots when creating BlockState objects with a raw getState() method, which was magnitudes slower than beforehand. Paper created a getState(boolean) method as a workaround, to allow plugins to opt-out of the snapshot behaviour. This is good, but many plugins don't realise and instead opt for the significantly slower snapshot variant.

Describe the solution you'd like.

Paper should change the default behaviour to not create snapshots, and instead have usecases that require snapshots go through getState(true) instead. This would make code performant by default, which fits Paper's general goals.

This change should be made across all method calls that create a BlockState instance, not just Block#getState().

Describe alternatives you've considered.

An alternative would be to deprecate the raw method entirely, so that developers are forced to confront the choice of "do i need a snapshot or not". This of course would mean that the change would not affect existing plugins, and would require developers to fix things.

Other

This should ideally not be too breaking of a change. A vast majority of plugins function identically with or without snapshots.

When the snapshot system was initially created, a Sign was 1600x slower than the non-snapshot equivalent. Signs being one of the simplest tile entities at the time. The game has only increased in complexity, and the slowdown is entirely dependent on the types and quantity of data that are being pulled in. In 1.21.4 chests can be upwards of 100000 times slower depending on what's inside them. I've seen numerous Spark reports that show half the entire server tick being used entirely by plugins doing a handful of chest accesses on chests that contain a large amount of data.

I've created a branch that appears to do this, but i haven't fully gone through and checked that it covers absolutely every code path. PR at #11913; should have a PR jar attached if someone wants to test it out with their plugins/server setups.

[Malfrador]

Generally I believe this is a really good idea, but I'm a bit worried about this being somewhat of a hidden behaviour change for the few percent of plugins that actually rely on it being a snapshot.

I do think this is fine and worth it due to the performance benefits, but the change should happen in a major release or with the first stable post-hardfork build, so that plugin developers get the chance to adapt to it and there is a clear cut between builds with and without this change.

[me4502]

Yeah I'd definitely expect a degree of change management to be required. This did suddenly switch to snapshots in the past too, so this method changing is not unprecedented. It does definitely make sense to go alongside some other cut-off point. Either while 1.21.4 is experimental, or alongside 1.21.5/1.22.0

[MiniDigger]

I know more than one plugin that relies on storing snapshots (and restoring them later by calling update) that this would break. I feel like deprecating to show people the new method is better