Add onBlockUpdate callback to modifiers and items

[Argmaster]

Extracted from #2834

[Argmaster]

it was branched from #2834, has same commit history + aad793e which removes devouring modifier

[IntegratedQuantum]

I'm honestly not sure about this, it's leaning into an a system (BlockUpdate command) that is already flawed in multiple ways.
I think in the future we'll likely see separate commands for the basic interactions (hitting a block and placing/right-clicking). From there we could make callbacks for damaging and breaking the block.

Maybe now would be the right time to fix this, and provide the better sync commands.

[Argmaster]

Maybe now would be the right time to fix this, and provide the better sync commands.

Now as in in the engine evolution stage, maybe. Now as in current linux timestamp, definitely not, we have already multiple large chains of changes and this change will require editing parts of code that are farily frequently modified and will be modified, so unless its done reasonably fast, it will drown in conflicts and I don't feel like repeating #1261 failure.

[IntegratedQuantum]

Well actually I would like to have this sooner rather than later. Sending the server data about swings is important to prevent cheat clients from breaking blocks instantly.

Maybe you don't need to make it block this PR, but I would appreciate if you could try to design the callback with that in mind → rename it to onBlockBreak and only run it when the block was broken (for now that can be detected by whether it costs durability)

[Argmaster]

for now that can be detected by whether it costs durability

That doesn't work for BaseItem which IMO should retain full symmetry with tools -> you can at least break plants with them.

I guess we could check if it costs durability or if it result in non-air block being replaced with air?

I am wondering if we should somehow support filling with fog in foggy environments? So block breaking would no longer mean always filling with air. Or do we always fill with air and fog/fluids need to rely on their own propagation? Probably latter is more managable.

This change (#2892) overlaps to some, significant, extent with #2891 and #2898 IMO we should focus on those and re-implement onBlockBreak as follow up, so its follows the pattern as closely as possible.
I would imagine callbacks being something like:

• onLeftClick
• onRightClick
• onBlockBreak -> does transform count? Should we support dedicated cb just for data change? onBlockTransform?
• onBlockPlace

But honestly I dunno, it needs deeper investigation. We somehow need to fit "no rotation update" and "no update callback" flags in sync updates for world edit.

I could start from the opposite side, trying to split block update in sync into block break and block place? But I still need to get closer to full picture.

[IntegratedQuantum]

does transform count? Should we support dedicated cb just for data change? onBlockTransform?

Ideally the target state should not be known at this point, it should be decided by the tool callback whether the result block is fully broken, partially updated (→chisel), or just gets a block entity update.

I could start from the opposite side, trying to split block update in sync into block break and block place?

Yeah, I think that would be a step in the right direction.