Introduce Item Lock API mainly for Client-Side inventory action prevention

[yuyaprgrm]

Introduction

Currently, PocketMine-MP have no API for item lock api provided via item's NBT(minecraft:item_lock).
The purpose of this PR is to provide an API for item locking and implement logic for server-side validation

Relevant issues

N/A

Changes

API changes

• add Item::setLockMode(?ItemLockMode $lockMode) : self
• add Item::getLockMode() : ?ItemLockMode
• add ItemLockMode enum

Behavioural changes

N/A

Backwards compatibility

N/A

Follow-up

Currently, value used in NBT is hardcoded. This value may be defined in BedrockProtocol.

Tests

Check whether it works correctly with ScriptPlugin below.

<?php

namespace famima65536\ItemLockTest;

use pocketmine\event\EventPriority;
use pocketmine\event\player\PlayerJoinEvent;
use pocketmine\item\ItemLockMode;
use pocketmine\item\VanillaItems;
use pocketmine\plugin\PluginBase;

/**
 * @name ItemLockTest
 * @main famima65536\ItemLockTest\Main
 * @version 0.1.0
 * @api 4.9.0
 * @description A plugin makes sure that Item::setLockMode() and Item::getLockMode() works well.
 * @author famima65536
 */


class Main extends PluginBase{

	protected function onEnable(): void{
		$this->getServer()->getPluginManager()->registerEvent(PlayerJoinEvent::class, function(PlayerJoinEvent $event) : void{
			$event->getPlayer()->getInventory()->setContents([
				VanillaItems::STICK()->setLockMode(ItemLockMode::SLOT()),
				VanillaItems::APPLE()->setLockMode(ItemLockMode::INVENTORY()),
			]);
		}, EventPriority::NORMAL, $this);
	}
}

[dktapps]

The server-side validation for this is incomplete. Since the current transaction system does not allow actions to be tracked when moving from one inventory to another, validation for this can't be easily implemented. This means that this effectively becomes a cosmetic-only change.

[yuyaprgrm]

Progress: this feature looks to be implementable with new inventory transaction system in current minor-next branch.
May I work this PR with rebasing and force-pushing?

[dktapps]

The core transaction system remains unchanged, and implementing core logic in the network layer is pretty dubious

[dktapps]

Blocked waiting on #6505

[dktapps]

I had a think about this, and realized it can probably be done without a revamp of the whole system.

Basically, this code would have to split $needItems and $haveItems into $needItemsByInventory and $haveItemsByInventory according to which inventory they came from (if they came from a SlotChangeAction).

Then, this code would have to be adapted to only look in the subset of items that are locked to the same inventory.

This way, the transaction would only balance if the same number of inventory-locked items were consumed & created by the same inventory.

Seems doable but not for the faint of heart.

Never mind, seems I misunderstood the function of the inventory lock. Apparently it allows moving from a chest -> player's inventory but not the other way round. It also allows moving from cursor <-> player inventory.

[dktapps]

PR is basically done but I think the terminology needs to be updated. ItemLockMode doesn't give much away, particularly since the intended function is actually to lock items specifically into a player's inventory. Without improvement, people might think this feature works on general inventories, like I did.