PlayerInteractEvent: added APIs to independently control reaction of item and block

[dktapps]

Introduction

this allows, for example, banning the usage of spawn eggs, without preventing opening of doors, without the need for item ID whitelists.

It also allows customizing the behaviour of item and block interactions when sneaking - it's now possible to force spawn eggs to work when sneaking, or force containers to open.

Finally, this also allows preventing any interaction at all without preventing block placement (by setting both to false). Since cancelling the event will typically prevent placement too (which might not be desired).

The naming of the functions is up for discussion, but the feature itself is stolen from Spigot and is much needed.

Relevant issues

• Fixes unable to cancel item activation without cancelling block activation #3267

Changes

API changes

• Added the following new API methods:
  • PlayerInteractEvent->useBlock() - returns whether the clicked block's onInteract() will be called
  • PlayerInteractEvent->useItem() - returns whether the held item's onInteractBlock() will be called
  • PlayerInteractEvent->setUseBlock()
  • PlayerInteractEvent->setUseItem()
    Note that setting these both to false does NOT cancel the event; rather, it makes the action behave as if the player was sneaking.

Behavioural changes

Backwards compatibility

Backwards compatible, but could cause unexpected results for plugins not aware of these features - e.g. a plugin may assume that chests are never opened if the player was sneaking, which this change would violate.

Tests

This has not yet been tested.

[dktapps]

This causes some buggy behaviour when using setUseItem(false) and setUseBlock(true) when using a lava bucket on a door: a ghost lava block is placed (unexpected) and the door is opened (expected). The lava doesn't exist on the server side, so it doesn't burn or spread.

[ColinHDev]

Would it help if I also test with this so the PR can get merged, or are you currently busy with the work on next-major?

[ShockedPlot7560]

I like the idea, I'd dig it up from the depths, soon

[dktapps]

I think the main issue with this is that World->useItemOn() and Player->onInteractBlock() can only return true (succeeded, don't resync anything) or false (failed, resync held item & clicked block). This PR introduces a situation where the interaction succeeds, but resync of held item and/or clicked block is still necessary, which is not currently possible to represent with this API.

I think fixing this will probably require BC breaks, unless deprecated wrappers are used.

[dktapps]

Turns out we can just always sync blocks during a block interaction. Since the client doesn't tell us what it expects, this is probably the best course of action anyway. Might even fix some issues in other areas.